Re: macppc can't modify pages in swap

Mark Kettenis <[email protected]> Tue, 25 Dec 2018 10:11:19 +0100 (CET)
Newsgroups gmane.os.openbsd.ppc,gmane.os.openbsd.bugs
Message-ID <[email protected]>
> Date: Tue, 25 Dec 2018 09:48:10 +0100
> From: Landry Breuil <[email protected]>
> 
> On Sun, Dec 23, 2018 at 09:20:11PM +0100, Mark Kettenis wrote:
> > > Date: Sun, 23 Dec 2018 19:35:02 +0100 (CET)
> > > From: Mark Kettenis <[email protected]>
> > > 
> > > > Date: Sun, 23 Dec 2018 12:26:17 +0100 (CET)
> > > > From: Mark Kettenis <[email protected]>
> > > > 
> > > > That's a very good find.  I think there still is a potential race in
> > > > your diff on MP systems since you save the bits before removing the
> > > > PTE from the has tables.  I'll see if I can come up with a better diff.
> > > 
> > > So here is the diff I propose instead.  This zaps the PTE before
> > > unlinking.  At that point the PTED_VA_MANAGED_M flag is still set so
> > > the MOD/REF accounting will happen.  A process running on the other
> > > CPU can't put the PTE back into the hash as we still hold the lock on
> > > the pmap.
> > > 
> > > Bootstrapping clang with this diff, and things are still running even
> > > though I've hit swap.  I'll give this a spin on an MP machine as well.
> > 
> > I fear sombody else needs to test on an MP machine as my dual G4
> > doesn't boot anymore :(.
> 
> I'll put this diff on macppc-*.p in the next bulk (in some days), both
> are MP. Maybe it'll fix the random ICEs when building c++ monsters,
> which probably hit swap as there's only 2Gb physmem...

Theo put the diff in snaps.  And yes, it will almost certainly fix
some of the random ICEs.