> Date: Wed, 2 Feb 2022 16:19:10 -0800 > From: guent...@openbsd.org > > On Wed, 2 Feb 2022, Alexander Bluhm wrote: > > On Wed, Feb 02, 2022 at 07:53:59PM +0000, Miod Vallat wrote: > > Hi, > > > > > > On my sparc64 machine > > regress/lib/libpthread triggers a panic. It > > happend with Feb 1 and Jan > > 31 snapshot. Jan 29 snapshot paniced > > > > > > > On Wed, Feb 02, 2022 at 07:53:59PM +0000, Miod Vallat wrote: > > > > Hi, > > > > > > > > On my sparc64 machine regress/lib/libpthread triggers a panic. It > > > > happend with Feb 1 and Jan 31 snapshot. Jan 29 snapshot paniced > > > > somewhere else. Test and console output below. > > > > > > > > *cpu1: pmap_enter: access_type exceeds prot > > > > > > > > bluhm > > > > > > Does the following diff help? > > > > Unfortunately not. Same panic. > > That suggests this is probably from the __HAVE_PMAP_MPSAFE_ENTER_COW > change. Can you try this diff, mirroring miod's? > > (Perhaps sparc64 has correct break-before-make semantics, I'm not wise > enough in sparc64 pmap to know)
I don't think it has. Anyway, ok kettenis@ for the diff. > Index: uvm/uvm_fault.c > =================================================================== > RCS file: /data/src/openbsd/src/sys/uvm/uvm_fault.c,v > retrieving revision 1.125 > diff -u -p -r1.125 uvm_fault.c > --- uvm/uvm_fault.c 1 Feb 2022 08:38:53 -0000 1.125 > +++ uvm/uvm_fault.c 3 Feb 2022 00:16:26 -0000 > @@ -1022,8 +1022,10 @@ uvm_fault_upper(struct uvm_faultinfo *uf > * uvm does it by inserting the new mapping RO and > * letting it fault again. > */ > - if (P_HASSIBLING(curproc)) > + if (P_HASSIBLING(curproc)) { > flt->enter_prot &= ~PROT_WRITE; > + flt->access_type &= ~PROT_WRITE; > + } > #endif > > /* > >