From owner-freebsd-current  Wed Jan 22 05:05:17 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id FAA03487
          for current-outgoing; Wed, 22 Jan 1997 05:05:17 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA03482;
          Wed, 22 Jan 1997 05:05:13 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id AAA18843; Thu, 23 Jan 1997 00:01:30 +1100
Date: Thu, 23 Jan 1997 00:01:30 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199701221301.AAA18843@godzilla.zeta.org.au>
To: mark@grondar.za, syssgm@devetir.qld.gov.au
Subject: Re: VM bogon? Was: Re: NIS breakage
Cc: dyson@freebsd.org, freebsd-current@freebsd.org
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>In fact, I'm now so keen on my hypothesis that I've written some code.
>Unfortunately, I have no -current box to test it on.  Thus, if Mr Murry
>wishes to risk all, the following patch may help.

I haven't checked yet, but perhaps the problem with vi completely paged
out is that the check accesses an unmapped PTE and the fault for this
refuses to map the page.

The validity checking for ordinary pages is fishy.  Consider repeatedly
reading a 2*N MB block on an N MB system.  After the first read, at
least half of the block should be user writable but swapped out.
Prefaulting it all in probably doesn't change this state.  It just
increases swap activity.  I think trapwrite() should only be called
when PG_W is clear.  This is the only case where the i386 loses.  In
particular, trapwrite() should not be called just to prefault pages
when PG_V is clear, PG_RW is set and PG_U is set.

Is it possible for a process to change the permissions for shared memory
while another process is accessing the memory in copyout()?

Bruce