I noticed a hung fstest (process hung in a syscall before it gets down to the fs) running generic/113 on mounts to Samba (the mount still works, but the test hangs) starting after 6.11-rc2 kernel (it fails on 6.11-rc4 but works on rc2). It is unlikely to be cifs.ko related since it still fails with 6.11-rc2 version of cifs.ko where kernel/VFS is rc4 but works if kernel/VFS is rc2 (ie fails even with older cifs.ko source built and run on 6.11-rc4 kernel) so is probably related to a VFS or netfs change. It also doesn't appear to be hung inside cifs.ko, but in the VFS layer: # cat /proc/fs/cifs/DebugData | grep "Active VFS Requests" Active VFS Requests: 0 it works on 6.11-rc2 but fails (hangs) on 6.11-rc4 in my tests to Samba localhost running generic/113 # cat /proc/fs/cifs/open_files # Version:1 # Format: # <tree id> <ses id> <persistent fid> <flags> <count> <pid> <uid> <filename> 0x4a8de66a 0x2cf91d3e 0x24d0faab 0xc002 1 5678 0 aiostress.5454.3.12 0x4a8de66a 0x2cf91d3e 0x36a30cae 0xc002 1 5678 0 aiostress.5454.3.14 # cat /proc/5678/stack [<0>] futex_wait_queue+0x66/0xa0 [<0>] __futex_wait+0x15b/0x1d0 [<0>] futex_wait+0x73/0x130 [<0>] do_futex+0x105/0x260 [<0>] __x64_sys_futex+0x128/0x200 [<0>] x64_sys_call+0x224c/0x22b0 [<0>] do_syscall_64+0x7e/0x170 [<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e I also didn't see anything obvious suspicious using trace-cmd tracing all cifs.ko tracepoints, but is there a trick to try to narrow down the hung syscall (and where) a little more easily? Any ideas? -- Thanks, Steve
