Re: [PATCH 01/11] fuse: fix livelock in synchronous file put from fuseblk workers

["Darrick J. Wong" <djwong@kernel.org>]

On Fri, Jun 06, 2025 at 03:54:50PM +0200, Miklos Szeredi wrote:
> On Sat, 31 May 2025 at 03:08, Darrick J. Wong <djwong@kernel.org> wrote:
> 
> > The best reason that I can think of is that normally the process that
> > owns the fd (and hence is releasing it) should be made to wait for
> > the release, because normally we want processes that generate file
> > activity to pay those costs.
> 
> That argument seems to apply to all fuse variants.  But fuse does get
> away with async release and I don't see why fuseblk would be different
> in this respect.
> 
> Trying to hack around the problems of sync release with a task flag
> that servers might or might not have set does not feel a very robust
> solution.
> 
> > Also: is it a bug that the kernel only sends FUSE_DESTROY on umount for
> > fuseblk filesystems?  I'd have thought that you'd want to make umount
> > block until the fuse server is totally done.  OTOH I guess I could see
> > an argument for not waiting for potentially hung servers, etc.
> 
> It's a potential DoS.  With allow_root we could arguably enable
> FUSE_DESTROY, since the mounter is explicitly acknowledging this DoS
> possibilty.

<nod> Looking deeper at fuse2fs's op_destroy function, I think most of
the slow functionality (writing group descriptors and the primary super
and fsyncing the device) ought to be done via FUSE_SYNCFS, not
FUSE_DESTROY.  If I made that change, I think op_destroy becomes very
fast -- all it does is close the fs and log a message.  The VFS unmount
code calls sync_filesystem (which initiates a FUSE_SYNCFS) which sounds
like it would work for fuse2fs.

Unhappily, libfuse3 doesn't seem to implement it:

$ git grep FUSE_SYNCFS
doc/libfuse-operations.txt:394:50. FUSE_SYNCFS (50)
include/fuse_kernel.h:186: *  - add FUSE_SYNCFS
include/fuse_kernel.h:670:      FUSE_SYNCFS             = 50,

--D

> Thanks,
> Miklos