Re: [PATCH 2/8] fuse: flush pending fuse events before aborting the connection

Darrick J. Wong
2025-09-30T17:56:34Z

On Tue, Sep 30, 2025 at 12:29:30PM +0200, Miklos Szeredi wrote:
> On Wed, 24 Sept 2025 at 22:54, Darrick J. Wong <djwong@kernel.org> wrote:
>
> > I think we don't want stuck task warnings because the "stuck" task
> > (umount) is not the task that is actually doing the work.
>
> Agreed.
>
> I do wonder why this isn't happening during normal operation. There
> could be multiple explanations:
>
> - release is async, so this particular case would not trigger the hang warning

<nod> I confirm that a normal release takes place asynchronously, so
nothing in the kernel gets hung up if ->release takes a long time.

It's only my new code that causes the hang warnings, and only because
it's using the non-interruptible wait_event variant to flush the
requests.

(I /could/ solve the problem differently by calling
wait_event_interruptible in a loop and ignoring the EINTR, but that
seems like a misuse of APIs.)

> - some other op could be taking a long time to complete (fsync?), but
> request_wait_answer() starts with interruptible sleep and falls back
> to uninterruptible sleep after a signal is received. So unless
> there's a signal, even a very slow request would fail to trigger the
> hang warning.

Yes, that's what happens if I inject a "stall" into, say, fallocate by
adding a gdb breakpoint on the fallocate handler in fuse4fs. The xfs_io
process calling fallocate() then just blocks in interruptible sleep
and I see no complaints from the hangcheck timer. But it's fallocate(),
which is quite interruptible.

Unmount is different -- the kernel has already torn down some of the
mount state, so we can't back out after some sort of interruption.

> A more generic solution would be to introduce a mechanism that would
> tell the kernel that while the request is taking long, it's not
> stalled (e.g. periodic progress reports).
>
> But I also get the feeling that this is not very urgent and possibly
> more of a test checkbox than a real life issue.

It's probably not an issue for 99% of filesystems and use cases, but
unprivileged userspace can set up the conditions for a stall warning.
Some customers file bug reports for /any/ kernel backtrace, even if it's
a stall warning caused by slow IO, so I'd prefer not to create a new
opening for this to happen.

--D

>
> Thanks,
> Miklos