fusefs: redo vnode attribute lockingHEADmain

Previously most fields in fuse_vnode_data were protected by the vnode
lock.  But because DEBUG_VFS_LOCKS was never enabled by default until
stable/15 the assertions were never checked, and many were wrong.
Others were missing.  This led to panics in stable/15 and 16.0-CURRENT,
when a vnode was expected to be exclusively locked but wasn't, for fuse
file systems that mount with "-o async".

In some places it isn't possible to exclusively lock the vnode when
accessing these fields.  So protect them with a new mutex instead.  This
fixes panics and unprotected field accesses in VOP_READ,
VOP_COPY_FILE_RANGE, VOP_GETATTR, VOP_BMAP, and FUSE_NOTIFY_INVAL_ENTRY.
Add assertions everywhere the protected fields are accessed.

Lock the vnode exclusively when handling FUSE_NOTIFY_INVAL_INODE.

During fuse_vnode_setsize, if the vnode isn't already exclusively
locked, use the vn_delayed_setsize mechanism.  This fixes panics during
VOP_READ or VOP_GETATTR.

Also, ensure that fuse_vnop_rename locks the "from" vnode.

Finally, reorder elements in struct fuse_vnode_data to reduce the
structure size.

Fixes:		283391
Reported by:	kargl, markj, vishwin, Abdelkader Boudih, groenveld@acm.org
MFC after:	2 weeks
Sponsored by:	ConnectWise
Reviewed by:	kib
Differential Revision: https://reviews.freebsd.org/D55230

0 files changed, 0 insertions, 0 deletions