Re: lockf broken with mpsafevfs (Re: tree may not be buildable for an hour.)

From: Jeff Roberson <jroberson_at_chesapeake.net>
Date: Tue, 25 Jan 2005 04:29:56 -0500 (EST)
On Tue, 25 Jan 2005, Robert Watson wrote:

>
> On Tue, 25 Jan 2005, Robert Watson wrote:
>
> > On Mon, 24 Jan 2005, Kris Kennaway wrote:
> >
> > > On Mon, Jan 24, 2005 at 05:56:48AM -0500, Jeff Roberson wrote:
> > > > That's all of it.  If you wait for your cvsup mirror to catch up, you can
> > > > try running with a smpsafe vfs by setting the debug.mpsafevfs tunable.
> > > > This option requires mpsafevm as well.  I have two known bugs that have
> > > > only been triggered by peter holm's excellent stress suite, but none are
> > > > known to cause problems if mpsafevfs is disabled, and none of them have
> > > > been seen on normal systems to my knowledge.
> > >
> > > Contention on lockf still causes a panic:
> > >
> > > panic: sleeping without a mutex
> >
> > Looks like lf_setlock() relies on tsleep(), which wants Giant.  It also
> > sounds like the lockf code isn't very MPSAFE and may require some
> > retrofitting to work with MPSAFE file systems -- the lock structures
> > appear not to have mutexes as interlocks, instead relying on Giant.
> > I've not read deeply enough to know if we could pull out it's local lock
> > implementation and replace it with something like an sx lock, but it
> > would be nice to.  Alternatively, using the vnode interlock mutex to
> > interlock it might be a good start.
>
> On further reading, definitely can't drop in a replacement lock type, but
> the first step will be to introduce interlocking of the lock type to
> protect lock state and switch to using msleep() with the interlock instead
> of tsleep() with Giant.

Thanks for the analysis robert.  I'll fix this straight away.

>
> Robert N M Watson
>
>
> >
> > Robert N M Watson
> >
> >
> > >
> > > panic(c072f601,0,c072f5f0,c0766008,c2ed7180) at panic+0x148
> > > msleep(c2ed1c00,0,168,c0766008,0) at msleep+0x8d
> > > lf_setlock(c2ed1c00,c0765fa0,2,ffffffff,ffffffff) at lf_setlock+0x1d2
> > > lf_advlock(e71e8ba4,c335a03c,0,0) at lf_advlock+0x200
> > > ufs_advlock(e71e8ba4,c298a170,c3c91300,e71e8cc0,c05990ce) at ufs_advlock+0x30
> > > VOP_ADVLOCK_AP(e71e8ba4,0,c07379d6,430,e71e8b70) at VOP_ADVLOCK_AP+0xa6
> > > kern_open(c298a170,bfbfed8e,0,21,8048f34) at kern_open+0x6be
> > > open(c298a170,e71e8d14,c,4,3) at open+0x36
> > > syscall(2f,2f,2f,ffffffff,bfbfeca4) at syscall+0x2a0
> > > Xint0x80_syscall() at Xint0x80_syscall+0x1f
> > > --- syscall (5, FreeBSD ELF32, open), eip = 0x280bde9f, esp = 0xbfbfebfc, ebp = 0xbfbfec74 ---
> > >
> > > The following blows it up:
> > >
> > > lockf .lock sleep 60 &
> > > lockf .lock sleep 60 &
> > >
> > > Kris
> >
> > _______________________________________________
> > freebsd-current_at_freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> >
>
Received on Tue Jan 25 2005 - 08:29:57 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:26 UTC