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

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

On Mon, Jun 09, 2025 at 11:13:26AM -0700, Darrick J. Wong wrote:
> 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,

...and it won't really work anyway since fuse_sync_fs doesn't upcall to
the fuse server if sb->s_root == NULL; and we can't do anything at that
point anyway because deactivate_locked_super -> fuse_kill_sb_anon has
already called fuse_conn_destroy to tear down the connection.

--D

> 
> > Thanks,
> > Miklos
>