Steve French <smfrench@xxxxxxxxx> writes: > when I tried this - it took much longer than expected to time out. For me the mount process never returns as the server is no longer responding to any requests and demultiplex thread is unable to detect server's unresponsiviness, therefore leaving the process stuck in wait_for_response() by not marking the mid for retry and waking it up. # ps -e -o stat,pid,comm,cmd |grep ^D D+ 726 mount.cifs mount.cifs //192.168.2.100/scratch /mnt/1 -o vers=3.1.1,username=testuser,password=xyz,echo_interval=5 # cat /proc/726/stack [<0>] wait_for_response+0x147/0x1a0 [cifs] [<0>] compound_send_recv+0x6b4/0x1150 [cifs] [<0>] cifs_send_recv+0x23/0x30 [cifs] [<0>] SMB2_negotiate+0x8b0/0x1c10 [cifs] [<0>] smb2_negotiate+0x52/0x70 [cifs] [<0>] cifs_negotiate_protocol+0x129/0x1c0 [cifs] [<0>] cifs_get_smb_ses+0x807/0x1150 [cifs] [<0>] cifs_mount_get_session+0x8a/0x210 [cifs] [<0>] dfs_mount_share+0x281/0x1040 [cifs] [<0>] cifs_mount+0xbd/0x3d0 [cifs] [<0>] cifs_smb3_do_mount+0x1e2/0xc80 [cifs] [<0>] smb3_get_tree+0x1bf/0x330 [cifs] [<0>] vfs_get_tree+0x4a/0x160 [<0>] path_mount+0x3c1/0xfb0 [<0>] __x64_sys_mount+0x1a6/0x1e0 [<0>] do_syscall_64+0xbb/0x1d0 [<0>] entry_SYSCALL_64_after_hwframe+0x77/0x7f If this happens after mounting the share, either smb2_reconnect_server() or any subsequent I/O will end up stuck in smb2_reconnect() under cifs_ses::session_mutex attempting to reconnect the session. Next I/O will block indefinitely under cifs_ses::session_mutex as it will need to reconnect the session as well. > How long do you expect mount to hang with your patch? @echo_interval seconds.
