From owner-cvs-all@FreeBSD.ORG Sun Aug 22 06:53:59 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE1DF16A4CE; Sun, 22 Aug 2004 06:53:59 +0000 (GMT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF05543D1F; Sun, 22 Aug 2004 06:53:59 +0000 (GMT) (envelope-from alc@cs.rice.edu) Received: from localhost (calypso.cs.rice.edu [128.42.1.127]) by cs.rice.edu (Postfix) with ESMTP id 4601A4ABFB; Sun, 22 Aug 2004 01:53:59 -0500 (CDT) Received: from cs.rice.edu ([128.42.1.30]) by localhost (calypso.cs.rice.edu [128.42.1.127]) (amavisd-new, port 10024) with LMTP id 13032-01-37; Sun, 22 Aug 2004 01:53:58 -0500 (CDT) Received: by cs.rice.edu (Postfix, from userid 19572) id D25E74ABFA; Sun, 22 Aug 2004 01:53:58 -0500 (CDT) Date: Sun, 22 Aug 2004 01:53:58 -0500 From: Alan Cox To: Brian Fundakowski Feldman Message-ID: <20040822065358.GM9106@cs.rice.edu> References: <20040822041018.GA937@green.homeunix.org> <20040822044936.GJ9106@cs.rice.edu> <20040822050155.GA1007@green.homeunix.org> <20040822052731.GL9106@cs.rice.edu> <20040822053535.GA931@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040822053535.GA931@green.homeunix.org> User-Agent: Mutt/1.4.2i X-Virus-Scanned: by amavis-20030616-p7 at cs.rice.edu cc: Alan Cox cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Robert Watson cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_fault.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2004 06:54:00 -0000 On Sun, Aug 22, 2004 at 01:35:35AM -0400, Brian Fundakowski Feldman wrote: > On Sun, Aug 22, 2004 at 12:27:31AM -0500, Alan Cox wrote: > > On Sun, Aug 22, 2004 at 01:01:55AM -0400, Brian Fundakowski Feldman wrote: > > > On Sat, Aug 21, 2004 at 11:49:36PM -0500, Alan Cox wrote: > > > > On Sun, Aug 22, 2004 at 12:18:49AM -0400, Robert Watson wrote: > > > > > > > > > > On Sun, 22 Aug 2004, Brian Fundakowski Feldman wrote: > > > > > > > > > > > Also, it was the system_map lock, so it was a mutex, not an sx. > > > > > > > > > > > > /Goes back to trying to figure out wtf portupgrade -rR kde\* keeps > > > > > > causing > > > > > > hangs, but only in X, not at the command line, and not seemingly > > > > > > dependant on AGP/X driver. > > > > > > > > > > I believe mutexes are alright also as long as you're careful about > > > > > sleeping and lock order. I.e., don't sleep while holding a > > > > > non-funnel-like mutex, etc. > > > > > > > > > > > > > We should never page fault on a system map. If that happens to you, > > > > it indicates an error. (In-kernel maps on which we do page fault, > > > > such as the pipe submap, are treated the same as user maps and utilize > > > > an sx lock.) > > > > > > vm_fault > > > vm_fault_wire > > > vm_map_wire > > > kmem_alloc > > > vm_ksubmap_init > > > cpu_startup > > > mi_startup > > > > > > > This is a call to vm_fault(), but not a page fault. This works > > without error because kmem_alloc() has preallocated and wired all of > > the required pages before calling vm_map_wire() (which calls > > vm_fault()). Specifically, the preallocation and wiring guarantees > > that vm_fault() will not follow any of the code paths on which it > > could sleep with the system map mutex held. (In fact, I believe that > > we are guaranteed that it will not sleep under any circumstances.) > > I know, but that has nothing to do with the fact that it's locking the > system map mutex, then Giant, which causes a lock order reversal. Do > you run WITNESS? If you do, you should see this in your startup. > Yes, I do. And, there is no complaint from WITNESS. Giant is already held by the initialization code. So, the acquisition of Giant inside of vm_fault() is recursive and thus not a lock-order violation. The bug was, however, causing Giant to be acquired once and released twice by vm_fault(). So, the first call to vm_fault() by vm_map_wire() would release the initialization code's hold on Giant. Once Giant became unlocked, the next call to vm_fault() by vm_map_wire() would tigger a lock-order reversal report. Alan