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: Tue, 25 Feb 2020 20:24:18 +0900

 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:
 
 https://nxr.netbsd.org/xref/src/sys/arch/mips/mips/vm_machdep.c#136
 
      117 #if (USPACE > PAGE_SIZE) || !defined(_LP64)
 ...
      135 #else
      136 	KASSERT(pmap_md_direct_mapped_vaddr_p(ua2));
      137 #endif
 
 If this KASSERT is commented out, system hangs when exec /sbin/init,
 and I cannot even enter ddb from console.
 
 Thanks,
 rin