Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 06 Mar 1995 08:40:29 -0800
From:      David Greenman <davidg@Root.COM>
To:        starkhome!gene@sbstark.cs.sunysb.edu (Gene Stark)
Cc:        current@FreeBSD.org, dyson@Root.COM
Subject:   Re: Page fault panics during make world in -current 
Message-ID:  <199503061640.IAA00715@corbin.Root.COM>
In-Reply-To: Your message of "Mon, 06 Mar 95 11:17:46 EST." <199503061617.LAA04199@starkhome.cs.sunysb.edu> 

next in thread | previous in thread | raw e-mail | index | archive | help
>OK, I understand, but the current instability of the system seems to indicate
>some sort of subtle problem, so I figure having a fresh eye take a look at
>the code might stand a chance of finding something.  I hope you'll pardon me
>if I "find" stuff that isn't a problem, as the assumptions/invariants, etc.
>that are inherent in this code take awhile to flesh out by reading the code
>over and over.

   Quite the opposite - I _encourage_ people to poke through the code and
point out strange things. Sorry if I ever suggested otherwise.

>I am still concerned about line 1046 of vfs_bio.c, though.  At line 1031,
>m is determined to be either invalid or busy.  At line 1046 there is a
>possibility of sleeping in the VM_WAIT.  If m is invalid, then I don't think
>there is anything stopping a pager from replacing m in the object with
>another page during the sleep, so that when we wake up again, m isn't a
>reference to the proper page in this object any more.  If m was busy,
>of course, this can't happen, because the pagers respect the busy flags
>and don't replace the pages in this case.

   That particular code section looks very familiar to me. :-) I've looked at
it several times in the past and recall mentioning the same problem to John.
At the time, John had a good explaination of why it wasn't a problem. The code
or the validity of the assumption might have changed since then (or John may
have just been wrong), and it's possible there is a problem. I can try to
bring this up with John over the phone, but he won't be able to look at it
until late this week (he's out of town on business - without his computer).

>I have the feeling a good test to exercise some of these potential problems
>would be to mmap() a file, then start accessing it via the mapped addresses,
>concurrently with another process that repeatedly truncates and rewrites it.

   I'm not sure what will happen if you truncate a mapped file. It should yank
all the pages away from all the processes that have it mapped - and further
accesses should create demand zero pages (and make the file sparsely allocated
if the references are to random places). Regular writes to the file should
cause the new information to just "appear" in the processes that have the file
mapped.

>Do you have a test like this?

   Not yet. :-)

-DG



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503061640.IAA00715>