git: Fix null dereference bug in fuse and re-enable it.

[Tomohiro Kusumi]

2024年3月14日(木) 15:29 Matthew Dillon <dillon at backplane.com>:
>
> All right.  I've been working on the fuse source for a few hours now and I've figured out pretty much everything.  I believe I can fix all the issues fairly easily.   There's one thing related to the ucred info that I haven't addressed yet, and an additional item related to dealing with failed write-appends (e.g. filesystem full)... currently does not undo the file size extend.   And the re-open code will need some investigation.
>
> * The file-handle issue relates to the FUSE kernel code issuing a FUSE_RELEASE on the file-handle inside the fuse_vop_close() function.  That leaves active directories in the namecache (when CD'd into a directory tree), and mmap()'d files, and multiple opens in trouble.

Have you checked this comment vvv and if so, does ^^^ address it ?
https://gitweb.dragonflybsd.org/dragonfly.git/blob/HEAD:/sys/vfs/fuse/fuse_file.c#l77
This was one of the main issues I saw in DragonFly, whether buffer
cache is used or not.

>
> * It was storing file handles in private data in the file pointer structure.  I don't know why but that's why it was having so much trouble with multiple open()s of the same file.

That's how Linux implements it, where fuse-fh is associated with
open-file structure.
fuse-fh typically stores file descriptor integer (like 3, 4, 5...)
used in userspace (e.g. fd for block device or regular file where
actual data is stored).

Using fuse_node to cache it is what FreeBSD FUSE used to do (not sure
now as it's been mostly rewritten), but then they had to share the
same fuse-fh for multiple fd's with the same open-mode or something.

> It was also trying to cache it in the fuse_node.  I'm changing that to put the active file handle in the fuse_node.  It should not even be aware of multiple open()s now.

Right, I wanted to stop doing this in fuse_node.

>
> * The solution is to move that RELEASE out of VOP_CLOSE and into VOP_INACTIVE.   DragonFly already has a flag that can be set to ask the kernel to deactivate a vnode as soon as the actual ref-count goes to zero which I will set to reduce the number of open file handles the userland process has to deal with.
>
> * The read/write code was a complete mess.  Basically I'm moving the VOP_READ and VOP_WRITE front-end to use generic buffer-cache operations.  VOP_BMAP is dummied up to allow the kernel to cluster on a file-by-file basis if it desires.  Then I have implemented a helper thread for the VOP_STRATEGY.  The bio will be queued to the helper thread which will then execute the RPCs.
>
> * I will temporarily run the I/Os synchronously from the helper thread until I get everything working.  But the I/O mechanism in general appears to be asynchronous so once I get things working well enough I will make VOP_STRATEGY asynchronous.
>
> So far everything is straight-forward.  It will take a day or two of testing to clean up the bugs due to the number of changes I've made, but I think I've got it.  It should wind up being pretty fast.  It might even be possible to cache a limited number of file handles to allow re-open's to avoid RPCs on cache hits.

I think sshfs is the best one for testing, but I recall I had to
modify code a bit to compile it on DragonFly 5 years ago.

>
> -Matt