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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
