git: 83d61d5b7300 - main - unionfs: do not force LK_NOWAIT if VI_OWEINACT is set

From: Jason A. Harmening <>
Date: Thu, 03 Feb 2022 02:58:22 UTC
The branch main has been updated by jah:


commit 83d61d5b73005b574eb41a291cb5a2a7d6ff733c
Author:     Jason A. Harmening <>
AuthorDate: 2022-01-30 21:03:18 +0000
Commit:     Jason A. Harmening <>
CommitDate: 2022-02-03 03:08:17 +0000

    unionfs: do not force LK_NOWAIT if VI_OWEINACT is set
    I see no apparent need to avoid waiting on the lock just because
    vinactive() may be called on another thread while the thread that
    cleared the vnode refcount has the lock dropped.  In fact, this
    can at least lead to a panic of the form "vn_lock: error <errno>
    incompatible with flags" if LK_RETRY was passed to VOP_LOCK().
    In this case LK_NOWAIT may cause the underlying FS to return an
    error which is incompatible with LK_RETRY.
    Reported by:    pho
    Reviewed by:    kib, markj, pho
    Differential Revision:
 sys/fs/unionfs/union_vnops.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/sys/fs/unionfs/union_vnops.c b/sys/fs/unionfs/union_vnops.c
index 28e306fdb3f8..8e881ffd19bb 100644
--- a/sys/fs/unionfs/union_vnops.c
+++ b/sys/fs/unionfs/union_vnops.c
@@ -1952,10 +1952,6 @@ unionfs_lock(struct vop_lock1_args *ap)
 	if ((revlock = unionfs_get_llt_revlock(vp, flags)) == 0)
 		panic("unknown lock type: 0x%x", flags & LK_TYPE_MASK);
-	if ((flags & LK_TYPE_MASK) != LK_DOWNGRADE &&
-	    (vp->v_iflag & VI_OWEINACT) != 0)
-		flags |= LK_NOWAIT;
 	 * During unmount, the root vnode lock may be taken recursively,
 	 * because it may share the same v_vnlock field as the vnode covered by