Re: [PATCH] fuse: abort connection on /dev/fuse flush to prevent deadlock

[Miklos Szeredi]

On Mon, 27 Jul 2026 at 19:30, syzbot <syzbot@xxxxxxxxxx> wrote:
>
> From: Kusaram Devineni <kusaram@xxxxxxxxxxx>
>
> A single-threaded FUSE daemon can deadlock if it mounts a filesystem and
> opens a file on it. When the process exits or calls close_range(), the
> kernel closes file descriptors in ascending numerical order.
>
> If the /dev/fuse file descriptor (e.g., fd 5) is closed first, filp_close()
> decrements the file reference count but defers the actual release (fput) to
> task work. As a result, the FUSE connection remains active.
>
> Next, when the FUSE file descriptor (e.g., fd 6) is closed, filp_close()
> calls fuse_flush(), which sends a synchronous FUSE_FLUSH request to the
> daemon. Since the daemon is the same thread that is currently blocked in
> the close() syscall, it cannot process the request. The FUSE_FLUSH request
> uses args.force = true, making the wait uninterruptible. The thread hangs
> forever, eventually triggering a hung task panic:

If the server doesn't reply to a FUSE_FLUSH request, the calling
process with be hung.   It could be due to a hung network connection
or whatever.

Is this special because sysbot was able to trigger this?   Why isn't
the fuse abort code taking care of this?

Thanks,
Miklos