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

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.

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