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

[Nick Hudson <nick.hudson%gmx.co.uk@localhost>]

On 25/02/2020 11:24, Rin Okuyama wrote:
> On 2020/02/24 9:29, Rin Okuyama wrote:
>> __HAVE_CPU_UAREA_ROUTINES is enabled for alpha, mips,
>> powerpc/{oae,ibm4xx,booke}, and riscv. I investigated whether it is
>> really necessary or not for these archs (except for riscv).
>>
>> In short, most of these archs do *not* need direct-mapped physically
>> contiguous u-area for now, as far as I can see (source code reading
>> and experiment on powerpc/oea, just experiment on other archs). Only
>> the exception is powerpc/ibm4xx, which should also be fixed.
>>
>> So is it time to retire __HAVE_CPU_UAREA_ROUTINES?
>
> Oops, mips64 depends on direct-mapped u-area (with UPAGES == 1);
> KASSERT fires on ERLITE (MIPS64_OCTEON) if __HAVE_CPU_UAREA_ROUTINES
> is turned off:

On mips64 iirc it's architecturally defined to have direct-map,
i.e. XKPHYS, so the fallback from cpu_uarea_alloc to
uvm_km_alloc "should" never happen.

This conditional is also slightly off I think

http://src.illumos.org/source/xref/netbsd-src/sys/uvm/uvm_glue.c#247

247	while (USPACE == PAGE_SIZE && USPACE_ALIGN == 0) {

the following is more correct (imo)

	while (USPACE == PAGE_SIZE &&
	    (USPACE_ALIGN == 0 || USPACE_ALIGN == PAGE_SIZE)) {


All that said I'm facing my own issues with uvm_pglistalloc not waiting
for > PAGE_SIZE physically contiguous allocations (2 pages in my case)

Nick