From owner-freebsd-bugs@FreeBSD.ORG Wed Jul 5 23:40:18 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30BE316A4DA for ; Wed, 5 Jul 2006 23:40:18 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B364143D49 for ; Wed, 5 Jul 2006 23:40:17 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k65NeH64026541 for ; Wed, 5 Jul 2006 23:40:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k65NeHKa026540; Wed, 5 Jul 2006 23:40:17 GMT (envelope-from gnats) Date: Wed, 5 Jul 2006 23:40:17 GMT Message-Id: <200607052340.k65NeHKa026540@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: "Eirik Oeverby" Cc: Subject: Re: kern/99094: panic: sleeping thread (Sleeping thread ... owns a non-sleepable lock) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eirik Oeverby List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2006 23:40:18 -0000 The following reply was made to PR kern/99094; it has been noted by GNATS. From: "Eirik Oeverby" To: "John Baldwin" Cc: Eirik =?iso-8859-1?Q?=D8verby?= , 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