should we propagate SMB error codes further?

Discussion:

Christoph Hellwig

2013-11-20 08:13:34 UTC

I'm seeing same interesting errors running against a server from a big
NAS vendor that shall remain unnamed:

p224160.955651] CIFS VFS: Unexpected lookup error -5
[224161.298853] CIFS VFS: Unexpected lookup error -5
[224161.643559] CIFS VFS: Unexpected lookup error -5
[224161.992309] CIFS VFS: Unexpected lookup error -5
[224162.333310] CIFS VFS: Unexpected lookup error -5
[224162.677982] CIFS VFS: Unexpected lookup error -5

Unfortunately it seems like a EIO is the catchall for unknown SMB
errors, so trying to debug this seems a bit hard. Should we maybe look
into propagating the SMB error codes further up the chain inside the
cifs driver instead of converting them at a fairly low level?

Volker Lendecke

2013-11-20 08:22:51 UTC

Permalink

Post by Christoph Hellwig
I'm seeing same interesting errors running against a server from a big

Just tell NetApp to fix their SMB implementation :-)

SCNR.

Volker

Jeff Layton

2013-11-20 11:26:19 UTC

Permalink

This post might be inappropriate. Click to display it.

Steve French

2013-11-21 18:35:38 UTC

Permalink

Post by Jeff Layton
On Wed, 20 Nov 2013 00:13:34 -0800

Post by Christoph Hellwig
I'm seeing same interesting errors running against a server from a big
p224160.955651] CIFS VFS: Unexpected lookup error -5
[224161.298853] CIFS VFS: Unexpected lookup error -5
[224161.643559] CIFS VFS: Unexpected lookup error -5
[224161.992309] CIFS VFS: Unexpected lookup error -5
[224162.333310] CIFS VFS: Unexpected lookup error -5
[224162.677982] CIFS VFS: Unexpected lookup error -5
Unfortunately it seems like a EIO is the catchall for unknown SMB
errors, so trying to debug this seems a bit hard. Should we maybe look
into propagating the SMB error codes further up the chain inside the
cifs driver instead of converting them at a fairly low level?

That makes a lot of sense. We could also get rid of some nasty NT
error->DOS error conversion code that way too.

At least in the SMB2/SMB3 case it is more direct onestep conversion
which helps.

Post by Jeff Layton
That said, if that NAS vendor is the one I'm thinking of, then
it's probable that it's just sending malformed responses and not sending
actual error codes at all.
You may be interested in this samba bug which has some details about
https://bugzilla.samba.org/show_bug.cgi?id=8914

I think generally with some of the NAS vendors we are better off mounting
with "vers=2.1" (or "vers=3.0" if more recent kernel) but probably not
till at least at 3.11 kernel. With the big move to SMB2.1 (Windows 7
and Mac) and
SMB3, there is presumably a lot less testing going on with cifs in some
of the NAS boxes.

--
Thanks,

Steve

Steve French

2013-11-21 18:29:10 UTC

Permalink

I wish we could extend the POSIX-like errors that the
kernel tolerates further (it is especially painful on mount where
a few more return codes would make life easier for
returning more specific mount errors, and I find it even harder on NFS
so it is not just cifs which suffers from wanting more error codes
to send back)

For your use case, you might try turning on the status code logging by
setting the CIFS_RC flag in the cifs debug flags at runtime
(unfortunately they are global not per-process).

"echo 2 > /proc/fs/cifs/cifsFYI"

Then you will see most of the nt status codes logged before they
are remapped.

e.g.
[ 9830.513514] Status code returned 0xc0000016
NT_STATUS_MORE_PROCESSING_REQUIRED
[ 9830.562929] Status code returned 0xc0000225 NT_STATUS_NOT_FOUND

(Maximal logging can be done by "echo 7 > /proc/fs/cifs/cifsFYI" which also
enables logging of CIFS_INFO and CIFS_TIMER events)

--
Thanks,

Steve