Re: [PATCH v2] fuse: permit freezing while waiting for request answer

Re: [PATCH v2] fuse: permit freezing while waiting for request answer

[test75]

Hi,

A field report that may help with the design discussion in this
thread. It is a case where freeze ordering alone would not help.

Setup: Ubuntu 26.04, 7.0.0-38-generic, Framework 13 (AMD, s2idle),
systemd 259, rclone 1.60 FUSE mounts (Google Drive, SMB, SFTP).

On lid close, a gvfs backend thread was in statx() on an rclone mount.
The rclone server was not frozen. It was waiting on the network, and
NetworkManager takes the Wi-Fi down as part of the sleep sequence.
That dependency is invisible to the kernel (the same point as the
sshfs/ssh example earlier in the thread). The request never completed,
so every suspend attempt failed. With the lid closed, logind retried
every ~100 s for 6 hours (about 210 cycles):

   Freezing user space processes failed after 20.003 seconds (3 tasks 
refusing to freeze, wq_busy=0):
   task:pool-906  state:D  pid:153003 tgid:6222 ppid:4922
    request_wait_answer+0xd8/0x280
    __fuse_simple_request+0x11f/0x370
    fuse_lookup_name+0xd6/0x260
    fuse_lookup+0x9d/0x1e0
    __lookup_slow+0x86/0x150
    lookup_slow+0x3c/0x60
    link_path_walk+0x348/0x410
    path_lookupat / filename_lookup / vfs_statx / do_statx
   task:pool-907  state:D  pid:171158 tgid:6222 ppid:4922
    request_wait_answer+0xd8/0x280
    __fuse_simple_request+0x11f/0x370
    fuse_dentry_revalidate+0x146/0x410
    lookup_fast+0x15c/0x170
    link_path_walk / ... / do_statx
   task:pool-908  state:D  pid:197388 tgid:6222 ppid:4922
    d_alloc_parallel+0x37b/0x460
    __lookup_slow+0x5d/0x150
    lookup_slow+0x3c/0x60
    link_path_walk / ... / do_statx

Two observations:

1. pool-906 and pool-907 would be covered by a freezable wait in
    request_wait_answer(). pool-906 sits in lookup_slow(), so it holds
    the parent's i_rwsem shared at freeze time.

2. pool-908 is the third task. It is not in FUSE code. It waits in
    d_alloc_parallel() on the in-lookup dentry owned by pool-906. So
    even with v2 applied, this suspend would still have failed. This
    matches the "contended VFS lock" limitation in the v2 changelog,
    but here the second waiter is a plain uninterruptible wait in the
    dcache rather than a lock. This pattern looks common in practice:
    desktop indexers and trash/thumbnail daemons stat the same
    directory from several threads.

The same signature shows up 1,000+ times in this machine's journal
since April (gvfsd-trash, localsearch-extractor as clients). I can
provide the full logs.

Thanks,
Phil