Dear Steve et al., I'm running Linux 4.18.6 in a corporate environment and now have the issue that listing directories lets the process hang interminably, loading one CPU by 100%. This does not happen every time (i.e. sometimes a directory listing completes). Note that this works solidly with 4.17.13. More verbatim: I had the problem the OP noted with 4.18.5 during upcall. I had vers=2.1 in the mount options since the servers used to not support vers=3. I didn't get a kernel oops but a hung mount process. It worked with 4.17.13. Reading this thread, I then dropped the vers= option and found that mounts worked again (still with 4.18.5) after confirming: nmap -Pn -p 445 --script smb-protocols ad PORT STATE SERVICE 445/tcp open microsoft-ds Host script results: | smb-protocols: | dialects: | NT LM 0.12 (SMBv1) [dangerous, but default] | 2.02 | 2.10 | 3.00 | 3.02 |_ 3.11 However, it may be that the actual mount uses version 2 still: Sep 06 09:43:18 cifs.upcall[15995]: key description: cifs.spnego;0;0;39010000;ver=0x2;host=xxx;ip4=xxx;sec=krb5;uid=0x3e8;creduid=0x3e8;user=root;pid=0x671b Sep 06 09:43:18 cifs.upcall[15995]: ver=2 Sep 06 09:43:18 cifs.upcall[15995]: host=xxx Sep 06 09:43:18 cifs.upcall[15995]: ip=xxx Sep 06 09:43:18 cifs.upcall[15995]: sec=1 Sep 06 09:43:18 cifs.upcall[15995]: uid=1000 Sep 06 09:43:18 cifs.upcall[15995]: creduid=1000 Sep 06 09:43:18 cifs.upcall[15995]: user=root Sep 06 09:43:18 cifs.upcall[15995]: pid=26395 Sep 06 09:43:18 cifs.upcall[15995]: get_cachename_from_process_env: pathname=/proc/26395/environ Sep 06 09:43:18 cifs.upcall[15995]: get_cachename_from_process_env: read to end of buffer (4096 bytes) Sep 06 09:43:18 cifs.upcall[15995]: get_existing_cc: default ccache is FILE:/tmp/krb5cc_1000 Sep 06 09:43:18 cifs.upcall[15995]: handle_krb5_mech: getting service ticket for xxx Sep 06 09:43:18 cifs.upcall[15995]: handle_krb5_mech: obtained service ticket Sep 06 09:43:18 cifs.upcall[15995]: Exit status 0 Thanks and best regards, Bernd
