We do not require devvp vnode locked for metadata io. It is typically not needed indeed, since correctness of the file system using corresponding block device ensures that there is no incorrect or racy manipulations.
But right now DEBUG_VFS_LOCKS option excludes both character device vnodes and completely destroyed (VBAD) vnodes from asserts. This is not too bad since WITNESS still ensures that we do not leak locks. On the other hand, asserts do not mean what they should, to the reader, and reliance on them being enforced might result in wrong code.
Fix this, but first either remove assertions not holding, or adding real locking where needed.
Note that ASSERT_VOP_LOCKED() still silently accepts NULLVP, I think it is worth fixing as well, in the next round.
Messages from individual commits:
Make locking assertions for VOP_FSYNC() more correct For devfs vnodes, it is fine to not lock vnodes for VOP_FSYNC(). Otherwise vnode must be locked exclusively, except for MNT_SHARED_WRITES().
freevnode(): lock the freeing vnode around destroy_vpollinfo()
ffs_snapshot: do not assert that um_devvp is locked It is not, and the lock is not needed there
mntfs: lock mntfs pseudo devfs vnode properly Require devvp locked for mntfs_freevp(), to have it locked around vgone(). Make that true for ffs, which is the only consumer of the interface.
ffs: Remove assertions about locked um_devvp in several places Namely, ffs_blkfree_cg(), and ffs_flushfiles().
getblk(): do not require devvp vnodes to be locked
geom_vfs: lock devvp in g_vfs_close() It is needed for g_vfs_close() invalidating the buffers. We rely on the vnode lock for correctness.
Per-commit view is available at https://kib.kiev.ua/git/gitweb.cgi?p=deviant3.git;a=shortlog;h=refs/heads/ufs