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

[test75]

Hi Miklos,

(Resending in-thread; my first attempt on Oct 23 lost its threading
headers and missed fuse-devel. Sorry for the noise.)

A field report on the contended case you raised, with one
data point for the "optionally freezable VFS locks" idea.

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, so
the request never completed (the same hidden dependency as the
sshfs/ssh example upthread). With the lid closed, logind retried every
~100 s for 6 hours, about 210 failed 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

pool-906 and pool-907 would be covered by v2. pool-906 holds the
parent's i_rwsem shared at freeze time, which is your contended case.

pool-908 is the one I wanted to point out. It does not wait on
i_rwsem: it waits in d_alloc_parallel() for the in-lookup dentry
owned by pool-906, and as far as I can tell d_wait_lookup() sleeps
TASK_UNINTERRUPTIBLE. So making i_rwsem and s_vfs_rename_mutex
freezable for fuse would still leave this suspend failing; the
in-lookup wait would need the same treatment.

This pattern looks common on desktops: indexers and trash/thumbnail
daemons stat the same directory from several threads. The same
signature appears 1,000+ times in this machine's journal since April
(gvfsd-trash, localsearch-extractor as clients). Full logs available
on request, and I am happy to test patches on this machine.

Thanks,
Phil