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

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

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

From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
To: Nick Hudson <nick.hudson%gmx.co.uk@localhost>, Jason Thorpe <thorpej%me.com@localhost>
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost, gnats-bugs%netbsd.org@localhost
Subject: Re: kern/54994: Critical bug in uarea_poolpage_alloc() for archs with
 __HAVE_CPU_UAREA_ROUTINES
Date: Wed, 26 Feb 2020 23:17:44 +0900

 Hi,
 
 On 2020/02/25 21:38, Nick Hudson wrote:> 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)
 
 Yeah, I think you are correct. Memory allocated in this loop is page
 itself, and therefore page-aligned. With this change, as well as
 similar one in uarea_poolpage_free(),
 
 https://nxr.netbsd.org/xref/src/sys/uvm/uvm_glue.c#277
      277 	if (USPACE == PAGE_SIZE && USPACE_ALIGN == 0) {
 --->
 		if (USPACE == PAGE_SIZE &&
 		    (USPACE_ALIGN == 0 || USPACE_ALIGN == PAGE_SIZE)) {
 
 kernel on mips64eb works fine without __HAVE_CPU_UAREA_ROUTINES.
 
 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?
 
 Thanks,
 rin