To clarify a few things: - are you saying that you had the original older dialect (SMB2.0, vers=2.0) signing problem, but now that that is resolved see occasional hangs in listing directories - do you see any correlation between the size of the directory and hangs - is a reconnect involved (I see mention of the krb5 upcall, which presumably could hang in a reconnect scenario if AD server were not available to refresh the ticket and it had expired)? You can see the number of reconnects (if any) in /proc/fs/cifs/Stats - if it is a reconnect any idea if intermittent network issue or hung server was the reason for the reconnect? - for the hung directory examples are you seeing them with smb3 (which presumably is the most common dialect being used and safest) or earlier dialect/ - what is the server type? On Thu, Sep 6, 2018 at 7:30 AM Dr. Bernd Feige <bernd.feige@xxxxxxxxxxxxxxxxxxxxx> wrote: > > 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 -- Thanks, Steve
