cvs commit: src/sys/vm vm_fault.c

Alan Cox alc at cs.rice.edu
Sat Aug 21 17:16:03 PDT 2004


On Sat, Aug 21, 2004 at 07:41:16PM -0400, Brian Fundakowski Feldman wrote:
> On Sat, Aug 21, 2004 at 06:31:34PM -0500, Alan Cox wrote:
> > On Sat, Aug 21, 2004 at 06:59:39PM -0400, Brian Fundakowski Feldman wrote:
> > > On Sat, Aug 21, 2004 at 07:20:21PM +0000, Alan Cox wrote:
> > > > alc         2004-08-21 19:20:21 UTC
> > > > 
> > > >   FreeBSD src repository
> > > > 
> > > >   Modified files:
> > > >     sys/vm               vm_fault.c 
> > > >   Log:
> > > >   Further reduce the use of Giant by vm_fault(): Giant is held only when
> > > >   manipulating a vnode, e.g., calling vput().  This reduces contention for
> > > >   Giant during many copy-on-write faults, resulting in some additional
> > > >   speedup on SMPs.
> > > >   
> > > >   Note: debug_mpsafevm must be enabled for this optimization to take effect.
> > > 
> > > This is very broken.  See included first attempt at fixing it without
> > > regard for actually trying to reimplement debug.mpsafenet for vnodes.
> > > 
> > 
> > Can you please explain what is broken?
> 
> #1. Lock order reversal.  Giant is acquired after the map read lock.

No, that is the order it has been in for months.  The other functions
that acquire a map lock and Giant do the same.

> #2. Unlocking Giant without it being locked.  This occurs in both
>     VM_UNLOCK_GIANT() lines I removed.  I know this because my machine
>     panicked on the other after I removed the first.

Yes, I see what happened.  I was able to reproduce it.  As the commit
explains, I failed to condition an early unlock of Giant on debug_mpsafevm.

Regards,
Alan


More information about the cvs-src mailing list