Date: Wed, 5 Jul 2006 23:40:17 GMT From: "Eirik Oeverby" <ltning@anduin.net> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/99094: panic: sleeping thread (Sleeping thread ... owns a non-sleepable lock) Message-ID: <200607052340.k65NeHKa026540@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/99094; it has been noted by GNATS.
From: "Eirik Oeverby" <ltning@anduin.net>
To: "John Baldwin" <jhb@freebsd.org>
Cc: Eirik =?iso-8859-1?Q?=D8verby?= <ltning@anduin.net>,
bug-followup@freebsd.org,
des@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200607052340.k65NeHKa026540>