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 02:04:20PM +0200, Miklos Szeredi wrote:
> On Wed, 24 Sept 2025 at 00:34, Darrick J. Wong <djwong@kernel.org> wrote:
> 
> > Conclusion: The loop is necessary to avoid softlockup warnings while the
> > fuse requests are processed by the server, but it is not necessary to
> > touch the watchdog in the loop body.
> 
> I'm still confused.
> 
> What is the kernel message you get?
> 
> "watchdog: BUG: soft lockup - CPU#X stuck for NNs!"
> 
> or
> 
> "INFO: task PROC blocked for more than NN seconds."

Oh!  The second:

INFO: task umount:1279 blocked for more than 20 seconds.
      Not tainted 6.17.0-rc7-xfsx #rc7
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this messag.
task:umount          state:D stack:11984 pid:1279  tgid:1279  ppid:10690
Call Trace:
 <TASK>
 __schedule+0x4cb/0x1a70
 ? vprintk_emit+0x10e/0x330
 schedule+0x2a/0xe0
 fuse_flush_requests_and_wait+0xe5/0x110 [fuse 810ab4024704e943aea18e16]
 ? cpuacct_css_alloc+0xa0/0xa0
 fuse_iomap_unmount+0x15/0x30 [fuse 810ab4024704e943aea18e1670e01b473ed]
 fuse_conn_destroy+0xdb/0xe0 [fuse 810ab4024704e943aea18e1670e01b473ed1]
 fuse_kill_sb_anon+0xb7/0xc0 [fuse 810ab4024704e943aea18e1670e01b473ed1]
 deactivate_locked_super+0x29/0xa0
 cleanup_mnt+0xbd/0x150
 task_work_run+0x55/0x90
 exit_to_user_mode_loop+0xa0/0xb0
 do_syscall_64+0x16b/0x1a0
 entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7f24c342ab77
RSP: 002b:00007ffd683ce5e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
RAX: 0000000000000000 RBX: 00005648fc1208a8 RCX: 00007f24c342ab77
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00005648fc1209c0
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000073
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f24c3566264
R13: 00005648fc1209c0 R14: 0000000000000000 R15: 00005648fc120790
 </TASK>

Apologies for my imprecise description of what I was trying to avoid; I
should have paid closer attention.

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.

I can copy the above into the commit message if that resolves the
confusion.

--D

> Thanks,
> Miklos