Page MenuHomeFreeBSD

Fix a vnode locking bug in fuse_vnop_advlock.
ClosedPublic

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

Details

Summary

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

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
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)."

sys/fs/fuse/fuse_vnops.c
429–433

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
sys/fs/fuse/fuse_vnops.c
429–433

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.