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

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

On Wed, Sep 24, 2025 at 08:19:59PM +0200, Miklos Szeredi wrote:
> On Wed, 24 Sept 2025 at 19:50, Darrick J. Wong <djwong@kernel.org> wrote:
> 
> > The wait_event_timeout() loop causes the process to schedule at least
> > once per second, which avoids the "blocked for more than..." warning.
> > Since the process actually does go to sleep, it's not necessary to touch
> > the softlockup watchdog because we're not preventing another process
> > from being scheduled on a CPU.
> 
> To be clear, this triggers because no RELEASE reply is received for
> more than 20 seconds?  That sounds weird.  What is the server doing
> all that time?
> 
> If a reply *is* received, then the task doing the umount should have
> woken up (to check fc->num_waiting), which would have prevented the
> hung task warning.
> 
> What am I missing?

(Note: I set /proc/sys/kernel/hung_task_timeout_secs to 10 seconds to
generate the 20 second warning)

I think what you're missing is the fuse server taking more than 20
seconds to process one RELEASE command successfully.  Say you create a
sparse file with 1 million extents, open it, and unlink the the file.
The file's still open, so the unlink can't truncate it or free it.

Next, you close the file and unmount the filesystem.  Inode eviction
causes a RELEASE command to be issued, so the fuse server starts
truncating the file to free it.  There's a million extents to free, but
the server is slow and can't process more than (say) 1000 extent freeing
operations per second.  That implies that the truncation will take 1000
seconds to complete, which means the reply to the RELEASE doesn't arrive
for 1000 seconds.  Meanwhile, the umount process doesn't see a change in
fc->waiting for 1000 seconds, so it isn't woken up for that amount of
time and we get the stuck task warning.

I think we don't want stuck task warnings because the "stuck" task
(umount) is not the task that is actually doing the work.  For an
in-kernel filesystem like XFS, the inode eviction process would be
generating enough context switches from all the metadata IOs to avoid
the hung task warning.

--D

> Thanks,
> Miklos
>