Page MenuHomeFreeBSD

unionfs: upgrade the vnode lock during fsync() if necessary
ClosedPublic

Authored by jah on Feb 10 2024, 4:38 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Nov 4, 4:11 AM
Unknown Object (File)
Sep 27 2024, 12:22 AM
Unknown Object (File)
Sep 9 2024, 11:14 PM
Unknown Object (File)
Sep 8 2024, 11:24 AM
Unknown Object (File)
Sep 8 2024, 2:35 AM
Unknown Object (File)
Sep 7 2024, 5:06 PM
Unknown Object (File)
Aug 30 2024, 10:49 AM
Unknown Object (File)
Aug 30 2024, 10:49 AM
Subscribers

Details

Summary

If the underlying upper FS supports shared locking for write ops,
as is the case with ZFS, VOP_FSYNC() may only be called with the vnode
lock held shared. In this case, temporarily upgrade the lock for
those unionfs maintenance operations which require exclusive locking.

While here, make unionfs inherit the upper FS' support for shared
write locking. Since the upper FS is the target of VOP_GETWRITEMOUNT()
this is what will dictate the locking behavior of any unionfs caller
that uses vn_start_write() + vn_lktype_write(), so unionfs must be
prepared for the caller to only hold a shared vnode lock in these
cases.

Found in local testing of unionfs atop ZFS with DEBUG_VFS_LOCKS.

MFC after: 2 weeks

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 55908
Build 52797: arc lint + arc unit

Event Timeline

jah requested review of this revision.Feb 10 2024, 4:38 PM
sys/fs/unionfs/union_vnops.c
1008

Is there a sense in downgrading?

sys/fs/unionfs/union_vnops.c
1008

I doubt it's strictly necessary, but I'd rather leave the lock state the way I found it if possible; this matches what I do in other similar functions as well.

This revision is now accepted and ready to land.Feb 11 2024, 6:41 AM