Date: Sat, 15 Feb 2014 14:12:40 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: freebsd-current@FreeBSD.org Subject: Re: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11) Message-ID: <52FF59B8.1080206@FreeBSD.org> In-Reply-To: <20140214191858.GC3783@caravan.chchile.org> References: <20140210205607.GA3783@caravan.chchile.org> <52F94923.60102@FreeBSD.org> <20140211093529.GB3783@caravan.chchile.org> <20140214191858.GC3783@caravan.chchile.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 14/02/2014 21:18 Jeremie Le Hen said the following:
> I've just got another occurence of the exact same panic. Any clue how
> to debug this?
Could you please obtain *vp from frame 12 ?
The problem seems to be happening in this piece of ZFS code:
if (cnp->cn_flags & ISDOTDOT) {
ltype = VOP_ISLOCKED(dvp);
VOP_UNLOCK(dvp, 0);
}
ZFS_EXIT(zfsvfs);
error = vn_lock(*vpp, cnp->cn_lkflags);
if (cnp->cn_flags & ISDOTDOT)
vn_lock(dvp, ltype | LK_RETRY);
ltype is apparently LK_SHARED and the assertion is apparently triggered by
EDEADLK error. The error can occur only if a thread tries to obtain a lock in a
shared mode when it already has the lock exclusively.
My only explanation of how this could happen is that dvp == *vpp and cn_lkflags
is LK_EXCLUSIVE. In other words, this is a dot-dot lookup that results in the
same vnode. I think that this is only possible if dvp is the root vnode.
I am not sure if my theory is correct though.
Also, I am not sure if zfs_lookup() should be prepared to handle such a lookup
or if this kind of lookup should be handled by upper/other layers. In this case
these would be VFS lookup code and nullfs code.
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52FF59B8.1080206>