kern/99094: panic: sleeping thread (Sleeping thread ... owns a non-sleepable lock)

[Eirik Oeverby]

The following reply was made to PR kern/99094; it has been noted by GNATS.

From: "Eirik Oeverby" <ltning at anduin.net>
To: "John Baldwin" <jhb at freebsd.org>
Cc: Eirik =?iso-8859-1?Q?=D8verby?= <ltning at anduin.net>,
 bug-followup at freebsd.org,
 des at freebsd.org
Subject: Re: kern/99094: panic: sleeping thread (Sleeping thread ... owns a 
     non-sleepable lock)
Date: Thu, 6 Jul 2006 01:32:24 +0200 (CEST)

 > On Saturday 01 July 2006 08:04, Eirik Øverby wrote:
 >> Hi again,
 >>
 >> I now have WITNESS and INVARIANTS in the kernel, and today it hung
 >> again. It looks somewhat different than before, but I am fairly
 >> certain it's the same error.
 >>
 >> Below you'll find the panic message, a bt, a ps, and then the output
 >> of a "c", which is exactly the same as the first message except it's
 >> not chopped off due to terminal size, and finally the panic resulting
 >> from the boot() call.
 >>
 >> /Eirik
 >>
 >> malloc(M_WAITOK) of "1024", forcing M_NOWAIT with the following non-
 >> sleepable locks held:
 >> exclusive sleep mutex vm object (standard object) r = 0
 >> (0xffffff0018f3fe00) locked @ /usr/src/sys/compat/linprocfs/lin9
 >> KDB: enter: witness_warn
 >> [thread pid 77487 tid 100323 ]
 >> Stopped at      kdb_enter+0x2f: nop
 >> db>
 >>
 >>
 >> db> bt
 >> Tracing pid 77487 tid 100323 td 0xffffff00531794c0
 >> kdb_enter() at kdb_enter+0x2f
 >> witness_warn() at witness_warn+0x2e0
 >> uma_zalloc_arg() at uma_zalloc_arg+0x1ee
 >> malloc() at malloc+0xab
 >> vn_fullpath() at vn_fullpath+0x56
 >> linprocfs_doprocmaps() at linprocfs_doprocmaps+0x31e
 >
 > Well, the problem is in linprocfs.  It is trying to do some very expensive
 > things while holding a mutex.  Here's the code excerpt:
 >
 > 		if (lobj) {
 > 			vp = lobj->handle;
 > 			VM_OBJECT_LOCK(lobj);
 > 			off = IDX_TO_OFF(lobj->size);
 > 			if (lobj->type == OBJT_VNODE && lobj->handle) {
 > 				vn_fullpath(td, vp, &name, &freename);
 > 				VOP_GETATTR(vp, &vat, td->td_ucred, td);
 > 				ino = vat.va_fileid;
 > 			}
 > 			flags = obj->flags;
 > 			ref_count = obj->ref_count;
 > 			shadow_count = obj->shadow_count;
 > 			VM_OBJECT_UNLOCK(lobj);
 >
 > The VM_OBJECT_LOCK() is a mutex, and it can't really hold a mutex while
 > calling things like vn_fullpath() and VOP_GETATTR() as those can block,
 > etc.
 > It needs to probably be reordered to grab copies of the object fields
 > under
 > the object lock, take a ref on the vnode (via vref) then do the
 > vn_fullpath()
 > and VOP_GETATTR() after dropping the vm object lock and finally do a
 > vrele()
 > to drop the vnode reference.  I'm cc'ing des@ as he's the linprocfs
 > maintainer and should be able to help with this further.
 
 Brilliant! Thanks!
 
 I have already disabled linprocfs, so I should expect the system to be
 stable now, then.
 
 PS: This was introduced between some of the RCs for 6.1, as far as I can
 remember.
 
 /Eirik