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

[Rick Macklem]

Andriy Gapon wrote:
> 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.
> 
I don't know if it ever occurs, but the NFS client has a check for
   if (vp != dvp)
      vn_lock(dvp...);  /* roughly what the code looks like. */
in the ISDOTDOT section of nfs_lookup().

I don't think this check would be harmful?

rick

> --
> Andriy Gapon
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe at freebsd.org"
>