Date: Tue, 21 Aug 2007 11:52:50 -0400 From: Jan Harkes <jaharkes@cs.cmu.edu> To: freebsd-current@freebsd.org Subject: Re: And probably the final crash for today's current :) (panic: filesystem goof: vop_panic[vop_print]) Message-ID: <20070821155250.GA30679@cs.cmu.edu> In-Reply-To: <20070820205201.GW2738@deviant.kiev.zoral.com.ua> References: <200708202340.29678.qpadla@gmail.com> <20070820205201.GW2738@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 20, 2007 at 11:52:01PM +0300, Kostik Belousov wrote:
> On Mon, Aug 20, 2007 at 11:40:29PM +0300, Nikolay Pavlov wrote:
> > I am testing latest coda client code.
> > After simple ls -l /coda i am getting this panic:
> >
> > vfs_badlock(c4448c80,e69729c0,c0b7efc0,c821ac3c,0) at vfs_badlock+0x23
> > assert_vop_locked(c821ac3c,c0acdaac,810,0,c65aca00,...) at
> > assert_vop_locked+0x50
> > VOP_OPEN_APV(c4448c80,e6972a18,1,c483a500,c4867ab0,...) at
> > VOP_OPEN_APV+0x8a
> > coda_open(e6972a8c,c0acdaac,c4864c00,0,e6972b80,...) at coda_open+0x11e
...
> Quite often, the "impossible" panics with vnode locking are happens
> because some other thread already paniced the kernel. Then, lockmgr
> passes all lock requests without actually locking. I would suggest
> looking around to make sure this is not the case there.
I think this is a valid vnode locking panic. In the coda_open function
(fs/coda/coda_vnops.c) we try to open the file which was handed down
by the userspace cache manager. However the code only grabs a reference,
there probably needs to be something extra around the VOP_OPEN to grab
the lock
I'm not totally up to speed on the FBSD locking, but I think the call to
VOP_OPEN needs to be surrounded by
vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td); and
...
VOP_UNLOCK(vp, 0, td);
I'm resyncing my freebsd install with current to see if I can reproduce
the panic and if this actually fixes it.
Jan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070821155250.GA30679>