> Date: Wed, 2 Feb 2022 16:19:10 -0800
> From: [email protected]
>
> 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
>
> /*
>
>
