On Thu, May 29, 2025 at 01:08:25PM +0200, Miklos Szeredi wrote:
> On Thu, 22 May 2025 at 02:02, Darrick J. Wong <djwong@xxxxxxxxxx> wrote:
>
> > Fix this by only using synchronous fputs for fuseblk servers if the
> > process doesn't have PF_LOCAL_THROTTLE. Hopefully the fuseblk server
> > had the good sense to call PR_SET_IO_FLUSHER to mark itself as a
> > filesystem server.
>
> The bug is valid.
>
> I just wonder if we really need to check against the task flag instead
> of always sending release async, which would simplify things.
>
> The sync release originates from commit 5a18ec176c93 ("fuse: fix hang
> of single threaded fuseblk filesystem"), but then commit baebccbe997d
> ("fuse: hold inode instead of path after release") made that obsolete.
>
> Anybody sees a reason why sync release for fuseblk is a good idea?
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. It's just this weird case where the fd
already got closed but aio is still going in the background.
(yeah, everyone hates aio ;))
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.
--D
> Thanks,
> Miklos
