From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alexander Viro <viro@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] paging
In-Reply-To: <20010108093902.E5F6E199D7@mail.cse.psu.edu>
Message-ID: <Pine.GSO.4.21.0101080444090.2221-100000@weyl.math.psu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Date: Mon,  8 Jan 2001 05:02:51 -0500
Topicbox-Message-UUID: 47bb2916-eac9-11e9-9e20-41e7f4b1d025



On Mon, 8 Jan 2001 forsyth@caldo.demon.co.uk wrote:

> - it can happen with paging to local disc
> - it CAN happen when paging over an ethernet to a file from a file server
> - it can lead to process hangs or traps; rio and acme are common targets
> - to judge from last-write times on the paging files, the problem is caused by paging
> - uniprocessors are affected
> - we most easily provoke it using charon to read huge pages on slashdot(!)
> - rio and acme (and emu) use rfork(RFMEM).  coincidence?
> - it did not happen with 2nd edition on any platform
> 
> at one point it seemed that it might be related to shared text/memory, because
> it once left a particular program corrupted but enough elsewhere was
> running that we could look at it (normally it damages enough of the interface
> that it is hard to debug).  i'm still not convinced.

	Just a gut feeling: procflushseg() and stuff triggered by it.
Check for situations when process gets created in the middle of procflushseg().
I didn't look deep enough, but it just screams "races will grow here, even
if there is none right now"...