Fix two locking violations that could happen during execve, while
executing a file stored on fusefs. Both would cause panics on an
INVARIANTS kernel after 15.0, or a DEBUG_VFS_LOCKS kernel prior to that.
- Don't assume that the vnode is exclusively locked during VOP_CLOSE. It usually is thanks to !MNTK_LOOKUP_SHARED, but isn't during execve, which locks the vnode outside of the lookup path.
- Totally rewrite fuse_io_invalbuf. It's had a number of problems ever since its original introduction[^1]:
- Don't assume that the vnode is exclusively locked. That assumption failed during execve just like the assumption in fuse_vnop_close.
- Don't livelock forever if vinvalbuf returns ENOSPC or EDQUOT.
- Don't attempt to handle multiple threads calling this function at the same time. That would be impossible if the vnode truly were exclusively locked. So the code was dead. Or it would've been, if the assumption hadn't been wrong. Furthermore, both vinvalbuf and vnode_pager_clean_sync only require a shared vnode lock, and are already capable of dealing with multiple simultaneous callers.
- Using fvdat->flag in this way would require some sort of mutex protection, if the vnode weren't exclusively locked.
- Add a new test case that triggers both of the aforementioned panics.
[^1]: https://github.com/glk/fuse-freebsd/commit/efe6eb3005e7633b4e31d5e453eacbaa0cba42fa
PR: 295957
Reported by: dan.kotowski@a9development.com
MFC after: 2 weeks
Sponsored by: ConnectWise