panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11)

[Andriy Gapon]

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