NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/54994: Critical bug in uarea_poolpage_alloc() for archs with __HAVE_CPU_UAREA_ROUTINES

The following reply was made to PR kern/54994; it has been noted by GNATS.

From: Rin Okuyama <>
To: Jason Thorpe <>
Cc: Nick Hudson <>,,,,
Subject: Re: kern/54994: Critical bug in uarea_poolpage_alloc() for archs with
Date: Thu, 27 Feb 2020 00:13:08 +0900

 On 2020/02/26 23:32, Jason Thorpe wrote:
 >> On Feb 26, 2020, at 6:17 AM, Rin Okuyama <> wrote:
 >> So, all ports including mips64 do not need CPU_UAREA_ROUTINES anymore,
 >> as far as I can see. Can we try turning off __HAVE_CPU_UAREA_ROUTINES to
 >> see what happens, or should we be more careful?
 > Platforms never "needed" __HAVE_CPU_UAREA_ROUTINES ... we didn't always have them.
 > I think we should keep them ... they are a useful optimization when they can do their work effectively.  However, we need to ensure that when they can't meet their constraints that the fallback still works.
 Certainly. Then, what should we do?
 Until now, we've learned:
 (1) uarea_poolpage_alloc() can fall back into uvm_km_alloc():
      This does not work if low-level routines need physically
      contiguous (i.e., direct-mapped) pages for u-area.
 (2) However, all ports with __HAVE_CPU_UAREA_ROUTINES actually do
      *not* need contiguous u-area anymore, as far as we can see.
 (3) Unfortunately, (2) does not mean that fallback of (1) is safe.
      If some ports, that need direct-mapped u-area, bump USPACE from
      1 to 2 (or more), fallback of uvm_km_alloc() results in memory
      corruption. This is what we observed on powerpc/ibm4xx.
 So, we have some options to do:
 (a) Add MD flag to forbid fallback of uvm_km_alloc().
 Or if this seems too much,
 (b) Leave some comments in uarea_poolpage_alloc().

Home | Main Index | Thread Index | Old Index