Page MenuHomeFreeBSD

Fix a vnode locking bug in fuse_vnop_advlock.

Authored by asomers on Jan 2 2021, 11:13 PM.



Fix a vnode locking bug in fuse_vnop_advlock.

It was introduced by subversion r346170.

MFC after: 2 weeks

Test Plan

Existing test suite with DEBUG_VFS_LOCKS

Diff Detail

R10 FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

Ok, so the bug was that we never took any lock at all? But we're also moving a block of code surrounding the new vn_lock(); operation, which isn't related to our not-locking-the-vp-bug. It looks like we want to reject EINVAL flags before we start locking, which is fine. I would just like to see a better commit message than "fix a [non-specific] bug." Something like "add missing lock in fuse advlock. also, reject invalid parameters sooner (style)."


Is assuming v_mount is non-NULL and of type struct fuse_data * with vp unlocked safe?

This revision is now accepted and ready to land.Jan 3 2021, 12:58 PM

Good question. I don't know what protects a vnode's v_mount field. But I see that it's checked without a vnode lock elsewhere, in ext2_pathconf, nfs_advlockasync, nfs_advise, and vn_generic_copy_file_range. So I'm going to assume that it's ok.