Date: Sun, 22 Aug 2004 00:27:31 -0500 From: Alan Cox <alc@cs.rice.edu> To: Brian Fundakowski Feldman <green@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm vm_fault.c Message-ID: <20040822052731.GL9106@cs.rice.edu> In-Reply-To: <20040822050155.GA1007@green.homeunix.org> References: <20040822041018.GA937@green.homeunix.org> <Pine.NEB.3.96L.1040822001718.95496H-100000@fledge.watson.org> <20040822044936.GJ9106@cs.rice.edu> <20040822050155.GA1007@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.) Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040822052731.GL9106>