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)
Philip
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
/*
