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

Eirik Oeverby ltning at
Wed Jul 5 23:40:18 UTC 2006

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

From: "Eirik Oeverby" <ltning at>
To: "John Baldwin" <jhb at>
Cc: Eirik =?iso-8859-1?Q?=D8verby?= <ltning at>,
 bug-followup at,
 des at
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

More information about the freebsd-bugs mailing list