Date: Mon, 4 Mar 2024 18:51:45 GMT From: "Jason A. Harmening" <jah@FreeBSD.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-branches@FreeBSD.org Subject: git: d0bb255d1fcb - stable/14 - VFS: update VOP_FSYNC() debug check to reflect actual locking policy Message-ID: <202403041851.424Ipj0g009574@gitrepo.freebsd.org>
next in thread | raw e-mail | index | archive | help
The branch stable/14 has been updated by jah: URL: https://cgit.FreeBSD.org/src/commit/?id=d0bb255d1fcbf4baff4cc43df684deb2ecd2f96d commit d0bb255d1fcbf4baff4cc43df684deb2ecd2f96d Author: Jason A. Harmening <jah@FreeBSD.org> AuthorDate: 2023-12-26 02:02:25 +0000 Commit: Jason A. Harmening <jah@FreeBSD.org> CommitDate: 2024-03-04 18:30:27 +0000 VFS: update VOP_FSYNC() debug check to reflect actual locking policy Shared vs. exclusive locking is determined not by MNT_EXTENDED_SHARED but by MNT_SHARED_WRITES (although there are several places that ignore this and simply always use an exclusive lock). Also add a comment on the possible difference between VOP_GETWRITEMOUNT(vp) and vp->v_mount on this path. Found by local testing of unionfs atop ZFS with DEBUG_VFS_LOCKS. Reviewed by: kib, olce Differential Revision: https://reviews.freebsd.org/D43816 (cherry picked from commit 9530182e371dee382b76d8594f65633a304b396f) --- sys/kern/vfs_subr.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index b9e92b5b9812..d1c17dca37d4 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -5845,7 +5845,22 @@ vop_fsync_debugprepost(struct vnode *vp, const char *name) { if (vp->v_type == VCHR) ; - else if (MNT_EXTENDED_SHARED(vp->v_mount)) + /* + * The shared vs. exclusive locking policy for fsync() + * is actually determined by vp's write mount as indicated + * by VOP_GETWRITEMOUNT(), which for stacked filesystems + * may not be the same as vp->v_mount. However, if the + * underlying filesystem which really handles the fsync() + * supports shared locking, the stacked filesystem must also + * be prepared for its VOP_FSYNC() operation to be called + * with only a shared lock. On the other hand, if the + * stacked filesystem claims support for shared write + * locking but the underlying filesystem does not, and the + * caller incorrectly uses a shared lock, this condition + * should still be caught when the stacked filesystem + * invokes VOP_FSYNC() on the underlying filesystem. + */ + else if (MNT_SHARED_WRITES(vp->v_mount)) ASSERT_VOP_LOCKED(vp, name); else ASSERT_VOP_ELOCKED(vp, name);
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202403041851.424Ipj0g009574>