linux-kernel - Re: "CIFS VFS: server not responding" with some client/server combinations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <524f69650710261702u5ff24c25qa2597dca70df24f0@mail.gmail.com>
Date:	Fri, 26 Oct 2007 19:02:17 -0500
From:	"Steve French" <smfrench@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: "CIFS VFS: server not responding" with some client/server combinations

> often I get "CIFS VFS: server not responding".
> together with "CIFS VFS: No response for cmd 50 mid xxx" The xxx number
> seems to vary.   The problem seems to be triggered by any operation
> which touches lots of  files quickly. E.g.
> by copying source file directories onto or from it or simply by find.
>
> Copying single larger files (I generated a 100MB file with dd) don't seems
> to hurt.
>
> Interestinly -- this is where the really strange part comes -- it seems to
> work on the client which has debian Etch

There are a couple of common ways to attack this kind of problem,
to identify if the server is hanging up or the client or network stack is
losing the response.    There were some (now fixed) bugs in
cifs_demultiplex_thread (whose frequency should have been very rare, but
seemed to be more common on some distros) which could cause
responses to be discarded by the client.

I typically would run a wireshark trace so I could look at whether the
server really did respond (you can look at the mid to correlate the
trace with the dmesg log warning).  There is another way to see
if the server is getting slow (but not so slow that the client
is giving up) - by turning on CONFIG_CIFS_STATS2 (CIFS "Extended Statistics"
in menuconfig) in which case "slow" (longer than 1 second) responses are
logged.   This can show problems with the server response long before we
reach the catastrophic more than 20 second delays you may be seeing.

You may want to build the current cifs backport of the most recent
fixes for cifs.ko (source at
http://pserver.samba.org/samba/ftp/cifs-cvs/cifs-1.50c.tar.gz) to see
if the problem is problem was on the client and is already fixed.
There is one additional EAGAIN handling problem in cifs_demultiplex
which is in mainline but not in the cifs backport yet which will be in
cifs 1.51 (which should be out later in the month).

-- 
Thanks,

Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/