Re: panic: LK_RETRY set with incompatible flags (0x200400) or an

看板FB_current作者時間12年前 (2014/02/15 20:32), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串4/15 (看更多)
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-unsubscribe@freebsd.org"
文章代碼(AID): #1I_rv230 (FB_current)
討論串 (同標題文章)
完整討論串 (本文為第 4 之 15 篇):
文章代碼(AID): #1I_rv230 (FB_current)