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: Mon, 24 Feb 2020 09:29:58 +0900

 Jason, Nick, thank you for your kind comments!
 
 __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?
 
 Details:
 
 (1) powerpc
 
 For powerpc architectures, MMU is turned off by hardware when exception
 occurs. We need direct-mapped physically contiguous u-area, if we
 manipulate kernel stack in trap handlers, before MMU is reenabled.
 
 For powerpc/oea, external interruption handler used to do that. But it
 was rewritten to manipulate stack after MMU is enabled, from
 powerpc/trap_subr.S rev 1.67:
 
      http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/powerpc/powerpc/trap_subr.S#rev1.67
 
 Actually, kernel works fine on macppc (Mac mini G4) even if
 __HAVE_CPU_UAREA_ROUTINES is manually turned off; boots multiuser, and
 builds pkgsrc/lang/perl5 for example.
 
 For powerpc/ibm4xx, trap handlers are designed based on old powerpc/oea
 implementation. And interruption handler still manipulates kernel stack
 with MMU disabled. I thought it can be fixed mechanically, but something
 goes wrong with softint_dispatch(). I will examine further.
 
 For powerpc/booke, I'm not familiar to its architecture nor organization
 of kernel source codes. So I turned __HAVE_CPU_UAREA_ROUTINES off to see
 what happens. RB800 (MPC8544E) also boots multiuser and builds lang/perl5.
 
 (2) alpha, mips
 
 I'm also not familiar to these archs, so I did experiment to turn off
 __HAVE_CPU_UAREA_ROUTINES.
 
 For alpha, DS10 (21264A) boots multiuser, and builds lang/perl5.
 
 For mips, MobileGearII MC/R730 (VR4121; MIPS3 with ENABLE_MIPS_4KB_PAGE)
 also boots multiuser. I am too lazy to build perl on this machine, but
 hello world builds and runs at least :).