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 GaponReceived on Sat Feb 15 2014 - 11:13:38 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:46 UTC