upstream/opnsense-src
1
0
Fork 0
mirror of https://github.com/opnsense/src.git synced 2026-03-19 01:02:28 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

VFS: update VOP_FSYNC() debug check to reflect actual locking policy

Browse source 
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)
This commit is contained in:
Jason A. Harmening 2023-12-25 20:02:25 -06:00
parent ebe18cb1a5
commit d0bb255d1f
1 changed files with 16 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
sys/kern/vfs_subr.c
View file

@ -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);