https://bugs.kde.org/show_bug.cgi?id=520518
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from [email protected] --- Same kio-fuse + kio_filenamesearch combination here, still present with Plasma 6.7.4 / Frameworks 6.28.0. In my case it happened twice, both times after connecting an Android phone over USB. The workers spawned by kio-fuse end up blocked in state D on a FUSE request to kio-fuse's own mount, so they cannot be killed and every suspend attempt fails until the kio-fuse connection is aborted. Regarding the traversals under /run/user/$UID mentioned above: my data points to the kio-fuse mount point rather than the worker socket files. The root of the kio-fuse mount (/run/user/1000/kio-fuse-XXXXXX) contained a "filenamesearch" directory, so presumably any traversal that enters it makes kio-fuse start filenamesearch workers, which then block on the same mount. It may also relate to the CPU usage: after I aborted the connection, one of the workers kept burning CPU (its CPU time went from 3:36 to 4:57 between two consecutive checks) until I killed it. Details below. SUMMARY kio_filenamesearch workers started by kio-fuse get stuck forever in uninterruptible sleep (state D, in request_wait_answer) on a FUSE request to the kio-fuse mount. The tasks cannot be killed and the kernel freezer cannot freeze them, so every suspend attempt fails until the kio-fuse connection is aborted manually. This happened twice in one week, on the same boot, both times after connecting an Android phone. STEPS TO REPRODUCE This happened twice (Sep 23 and Sep 28), both times after connecting my phone. I have not reproduced it on purpose yet. 1. Connect an Android phone over USB in file transfer (MTP) mode. 2. Later, try to suspend (power button or "systemctl suspend"). 3. Suspend fails after the 20-second freezer timeout. kio_filenamesearch workers spawned by kio-fuse are stuck in state D on kio-fuse's own mount (details below), and they stay stuck even after the phone is unplugged. Additional notes: - The root of the kio-fuse mount contained a "filenamesearch" directory, so a filenamesearch:/ URL had been exposed through kio-fuse. - No kio_mtp worker was running when I inspected the system, but by then the phone had already been unplugged, so its worker may simply have exited. OBSERVED RESULT Occurrence 1 (Sep 23): suspend fails because the kernel freezer times out. systemd-sleep: Failed to freeze unit 'user.slice': Connection timed out kernel: PM: suspend entry (deep) kernel: Freezing user space processes failed after 20.002 seconds (2 tasks refusing to freeze, wq_busy=0): kernel: task:KIO::WorkerThre state:D stack:0 pid:43903 tgid:43883 ppid:2137 task_flags:0x400140 flags:0x00080802 kernel: Call Trace: kernel: __schedule+0x2c2/0x710 kernel: schedule+0x27/0xa0 kernel: request_wait_answer+0xe5/0x310 [fuse] kernel: __fuse_simple_request+0xd7/0x2e0 [fuse] kernel: fuse_send_open+0xe6/0x150 [fuse] kernel: fuse_file_open+0xe8/0x1c0 [fuse] kernel: fuse_do_open+0x18/0x30 [fuse] kernel: fuse_dir_open+0x64/0xc0 [fuse] kernel: do_dentry_open+0x12f/0x4c0 kernel: vfs_open+0x30/0xf0 kernel: do_open+0x172/0x420 kernel: path_openat+0x10a/0x2a0 kernel: do_file_open+0x117/0x1d0 kernel: do_sys_openat2+0x7b/0xe0 kernel: __x64_sys_openat+0x61/0xa0 kernel: do_syscall_64+0xe2/0x560 kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e (identical trace for the second task, pid 43969 / tgid 43906; "?" frames removed) systemd-sleep: Failed to put system to sleep. System resumed again: Device or resource busy The two tasks belonged to: 43883 /usr/libexec/kf6/kioworker /usr/lib64/qt6/plugins/kf6/kio/kio_filenamesearch.so 43906 /usr/libexec/kf6/kioworker /usr/lib64/qt6/plugins/kf6/kio/kio_filenamesearch.so The root of the kio-fuse mount (/run/user/1000/kio-fuse-fhZTCt) contained a single entry, "filenamesearch". Running "ls" on that directory also hung in state D and could not be killed ("timeout 5 ls ..." never returned). Writing 1 to /sys/fs/fuse/connections/145/abort (the kio-fuse connection) released all of them, and suspend worked afterwards. Occurrence 2 (Sep 28, same boot, new kio-fuse instance at /run/user/1000/kio-fuse-rJGKda): same suspend failure, now with 7 stuck threads. State right before aborting: PID TID STAT WCHAN COMMAND 85707 87228 Dl request_wait_answer KIO::WorkerThre 85764 87312 Dl request_wait_answer KIO::WorkerThre 85804 87298 Dl request_wait_answer KIO::WorkerThre 85827 87233 Dl request_wait_answer KIO::WorkerThre 85854 87363 Dl request_wait_answer KIO::WorkerThre 87258 87299 Dl request_wait_answer KIO::WorkerThre 87308 87364 Dl request_wait_answer KIO::WorkerThre $ pgrep -a kioworker 85707 [kioworker] <defunct> 85764 [kioworker] <defunct> 85804 [kioworker] <defunct> 85827 /usr/libexec/kf6/kioworker /usr/lib64/qt6/plugins/kf6/kio/kio_filenamesearch.so filenamesearch local:/run/user/1000/kiofuseUIKCdb.1.kioworker.socket 85854 [kioworker] <defunct> 87258 /usr/libexec/kf6/kioworker /usr/lib64/qt6/plugins/kf6/kio/kio_filenamesearch.so filenamesearch local:/run/user/1000/kiofuseDrGReM.2.kioworker.socket 87308 /usr/libexec/kf6/kioworker /usr/lib64/qt6/plugins/kf6/kio/kio_filenamesearch.so filenamesearch local:/run/user/1000/kiofusebgdOTw.3.kioworker.socket Pending requests per FUSE connection (/sys/fs/fuse/connections/<N>/waiting): fuse.kio-fuse /run/user/1000/kio-fuse-rJGKda 7 fuse.gvfsd-fuse /run/user/1000/gvfs 0 fuse.portal /run/user/1000/doc 0 So: - All 7 stuck threads are waiting on the kio-fuse mount (7 pending requests on that connection, none on the others). - The worker socket names (kiofuse*.kioworker.socket) indicate the workers were spawned by the kio-fuse daemon itself. - Four of the worker processes were already zombies, kept alive only by the thread stuck in D. This looks like a self-deadlock: kio-fuse starts filenamesearch workers, and those workers block on a FUSE request to kio-fuse's own mount, which never gets answered. I have not confirmed which path was being opened, nor how connecting the phone leads to these searches. EXPECTED RESULT - Workers spawned by kio-fuse should never be able to block on kio-fuse's own mount (e.g. filenamesearch should not descend into kio-fuse mount points, or kio-fuse should fail such requests instead of waiting). - A request kio-fuse cannot answer should eventually fail, instead of leaving unkillable D-state tasks that block suspend (see bug 525137). SOFTWARE/OS VERSIONS Operating System: Aurora 44 (Universal Blue, based on Fedora 44) KDE Plasma Version: 6.7.4 KDE Frameworks Version: 6.28.0 Qt Version: 6.11.1 Kernel Version: 7.1.4-200.fc44.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5500U with Radeon Graphics Memory: 16 GiB of RAM (14.4 GiB usable) Graphics Processor: AMD Radeon Graphics ADDITIONAL INFORMATION Workaround: a systemd service ordered Before=sleep.target that, for each kio-fuse mount whose /sys/fs/fuse/connections/<N>/waiting is > 0, writes 1 to .../abort, lazily unmounts it and kills the kio-fuse daemon (D-Bus reactivates it on demand). With it, suspend works again. Happy to share the script or collect more data (e.g. kio-fuse debug output) if useful. -- You are receiving this mail because: You are watching all bug changes.
