Re: lockmgr: thread 0xc385ebd0 unlocking unheld lock

From: John Baldwin <jhb_at_freebsd.org>
Date: Mon, 27 Mar 2006 13:18:49 -0500
On Sunday 26 March 2006 12:02, Joao Barros wrote:
> On 3/26/06, Joao Barros <joao.barros_at_gmail.com> wrote:
> > Last night I was mounting a windows share with mount_smbfs and
> > browsing it via apache and I got the machine to panic twice. I was
> > tired and went to bed.
> > Today I can't replicate the panic but this always happens when I unmount:
> >
> > I'm trying to replicate the panic, and if I can I'll post a followup.
> >
> 
> Here's the panic while doing a cvsup:
> 
> panic: mutex Giant not owned at /usr/src/sys/kern/vfs_subr.c:2025
> KDB: enter: panic
> [thread pid 979 tid 100090 ]
> Stopped at      kdb_enter+0x2b: nop
> db> where
> Tracing pid 979 tid 100090 td 0xc3573510
> kdb_enter(c06cc0e7) at kdb_enter+0x2b
> panic(c06cb401,c06dbed4,c06d5d7b,7e9,c3766000) at panic+0xbb
> --More--        _mtx_assert(c0733b28,1,c06d5d7b,7e9) at _mtx_assert+0x66
> vrele(c3766000,c34efc28,c34ef800,c3573510,d6aff82c) at vrele+0x4e
> smbfs_reclaim(d6aff82c) at smbfs_reclaim+0xc9
> VOP_RECLAIM_APV(c3735a60,d6aff82c) at VOP_RECLAIM_APV+0x7e
> vgonel(c3766410) at vgonel+0x12d
> vtryrecycle(c3766410,0,2,d6aff8ac,c059f18f) at vtryrecycle+0x107
> vnlru_free(1) at vnlru_free+0x14e
> getnewvnode(c06d3bc3,c351b000,c071e880,d6aff918,d6aff8f0) at getnewvnode+0x33
> ffs_vget(c351b000,5dbe1,2,d6aff97c) at ffs_vget+0xc2
> ufs_lookup(d6affa20) at ufs_lookup+0xaa2
> VOP_CACHEDLOOKUP_APV(c071e880,d6affa20) at VOP_CACHEDLOOKUP_APV+0x7e
> vfs_cache_lookup(d6affabc,c3819c30,0,d6affad8,c059a3fe) at vfs_cache_lookup+0xb2
> VOP_LOOKUP_APV(c071e880,d6affabc) at VOP_LOOKUP_APV+0x87
> lookup(d6affb48,0,0,c3573510,c381a000) at lookup+0x3f6
> namei(d6affb48,82b5304,0,0,c3544c30) at namei+0x382
> kern_lstat(c3573510,82b5304,0,d6affc1c) at kern_lstat+0x47
> lstat(c3573510,d6affd04,c0734404,0,c328cd00) at lstat+0x1b
> syscall(bfbf003b,bfbf003b,81d003b,bfbfed28,bfbfed1c) at syscall+0x27e
> Xint0x80_syscall() at Xint0x80_syscall+0x1f

Hmm, so if an MPSAFE vfs needs a vnode it might be recycling a vnode from
a non-MPSAFE vfs resulting in this.  Does getnewvnode() or some other function
in the recycling chain need to conditionally acquire Giant?

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
Received on Mon Mar 27 2006 - 16:30:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:54 UTC