git: 83d61d5b7300 - main - unionfs: do not force LK_NOWAIT if VI_OWEINACT is set
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 03 Feb 2022 02:58:22 UTC
The branch main has been updated by jah: URL: https://cgit.FreeBSD.org/src/commit/?id=83d61d5b73005b574eb41a291cb5a2a7d6ff733c commit 83d61d5b73005b574eb41a291cb5a2a7d6ff733c Author: Jason A. Harmening <jah@FreeBSD.org> AuthorDate: 2022-01-30 21:03:18 +0000 Commit: Jason A. Harmening <jah@FreeBSD.org> 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: https://reviews.freebsd.org/D34109 --- 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