]> git.baikalelectronics.ru Git - kernel.git/commit
cifs: when server doesn't set CAP_LARGE_READ_X, cap default rsize at MaxBufferSize
authorJeff Layton <jlayton@redhat.com>
Mon, 2 Jul 2012 11:24:25 +0000 (07:24 -0400)
committerSteven French <sfrench@w500smf.(none)>
Tue, 3 Jul 2012 17:54:42 +0000 (12:54 -0500)
commitc0587328909d9c30ee6af1266335212395c3b74e
tree57b1c6d90c394181c183978e2ed1d69b8b1ef4dc
parent51677141ee4463cdab211c894a8a645fe1da24de
cifs: when server doesn't set CAP_LARGE_READ_X, cap default rsize at MaxBufferSize

When the server doesn't advertise CAP_LARGE_READ_X, then MS-CIFS states
that you must cap the size of the read at the client's MaxBufferSize.
Unfortunately, testing with many older servers shows that they often
can't service a read larger than their own MaxBufferSize.

Since we can't assume what the server will do in this situation, we must
be conservative here for the default. When the server can't do large
reads, then assume that it can't satisfy any read larger than its
MaxBufferSize either.

Luckily almost all modern servers can do large reads, so this won't
affect them. This is really just for older win9x and OS/2 era servers.
Also, note that this patch just governs the default rsize. The admin can
always override this if he so chooses.

Cc: <stable@vger.kernel.org> # 3.2
Reported-by: David H. Durgee <dhdurgee@acm.org>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steven French <sfrench@w500smf.(none)>
fs/cifs/connect.c