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

Darrick J. Wong
2025-09-23T14:54:14Z

On Tue, Sep 23, 2025 at 01:11:39PM +0200, Miklos Szeredi wrote:
> On Tue, 16 Sept 2025 at 02:24, Darrick J. Wong <djwong@kernel.org> wrote:
>
> > + /*
> > + * Wait for all the events to complete or abort. Touch the watchdog
> > + * once per second so that we don't trip the hangcheck timer while
> > + * waiting for the fuse server.
> > + */
> > + smp_mb();
> > + while (wait_event_timeout(fc->blocked_waitq,
> > + !fc->connected || atomic_read(&fc->num_waiting) == 0,
> > + HZ) == 0)
>
> I applied this patch, but then realized that I don't understand what's
> going on here.

We go around this tight loop until either 1 second goes by, the fuse
connection drops, or the number of fuse commands hits zero. Non-timeout
Wakeups are stimulated by the wake_up_all(&fc->blocked_waitq) in
fuse_drop_waiting() after the request is completed or aborted.

The loop body touches the soft lockup watchdog so that we don't get hung
task warnings while waiting for a possibly large number of RELEASE
requests (or whatever's queued up at that point) to be processed by the
server. I didn't use wait_event_killable_timeout because I don't know
how to clean up an in-progress unmount midway through.

> Why is this site special? Should the other waits for server response
> be treated like this?

I'm not sure what you're referring to by "special" -- are you asking
about why I added the touch_softlockup_watchdog() call here but not in
fuse_wait_aborted()? I think it could use that treatment too, but once
you abort all the pending requests they tend to go away very quickly.
It might be the case that nobody's gotten a warning simply because the
aborted requests all go away in under 30 seconds.

--D

> Thanks,
> Miklos