From owner-freebsd-current Mon Mar 6 07:35:15 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA08122 for current-outgoing; Mon, 6 Mar 1995 07:35:15 -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 HAA08116 for ; Mon, 6 Mar 1995 07:35:08 -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 HAA03026; Mon, 6 Mar 1995 07:34:34 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.9/8.6.5) with SMTP id HAA00614; Mon, 6 Mar 1995 07:34:33 -0800 Message-Id: <199503061534.HAA00614@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 08:56:07 EST." <199503061356.IAA03953@starkhome.cs.sunysb.edu> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 06 Mar 1995 07:34:32 -0800 Sender: current-owner@FreeBSD.org Precedence: bulk >Actually, none of the calls to vm_page_lookup() in vfs_bio.c lock the >VM object first. However, after some of them, there are even calls to >VMWAIT while the pointer to the page is held (e.g. line 1046). >Why are you sure that the page will still be valid when VMWAIT is over? >The page fault handler goes to great pains to keep checking that a >page lookup is still valid after a sleep might have occurred, so I don't >think it can really be safe to lookup a page with the object unlocked >and then do arbitrary stuff. The code in vfs_bio.c is quite complex. John and I have each gone through this several times trying to find problems like you've mentioned. We're pretty sure that the page in question is always made 'busy' or 'bmapped' before any calls to VM_WAIT (or any other sleep) could otherwise lose the page. I'm not saying that we might not have missed something...but we have looked at this specific potential problem more than once. The object itself can't go away because a reference is held to it. -DG