From owner-freebsd-current Mon Mar 6 08:41:03 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA10521 for current-outgoing; Mon, 6 Mar 1995 08:41:03 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id IAA10515 for ; Mon, 6 Mar 1995 08:40:58 -0800 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id IAA03140; Mon, 6 Mar 1995 08:40:31 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.9/8.6.5) with SMTP id IAA00715; Mon, 6 Mar 1995 08:40:30 -0800 Message-Id: <199503061640.IAA00715@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol 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 In-reply-to: Your message of "Mon, 06 Mar 95 11:17:46 EST." <199503061617.LAA04199@starkhome.cs.sunysb.edu> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 06 Mar 1995 08:40:29 -0800 Sender: current-owner@FreeBSD.org Precedence: bulk >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