[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
> On Feb 26, 2020, at 7:13 AM, Rin Okuyama <rokuyama.rk%gmail.com@localhost> wrote:
> 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.
AFAIK, they *never* did. Certainly, Alpha does not require a physically-contiguous u-area, neither does x86. Heck, neither does MIPS, assuming wired TLB entries are used to keep the kernel stack mapped. A physically contiguous u-area is ONLY required if you are using a direct-mapped segment to provide the address of the u-area to the CPU.
> (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().
We need to understand why the fallback fails on the platforms where it does fail. The following statements should all be true:
1- If physically-contiguous pages for the u-area can be allocated and mapped with a direct-mapped segment, we should be able to use that.
2- If phusically-contiguous pages for the u-area cannot be allocated, then the system should be able to use a u-area that is virtually mapped but not physically contiguous.
(2) used to be the way the system always worked for UPAGES > 1.
Main Index |
Thread Index |