aboutsummaryrefslogtreecommitdiffstats
path: root/fs/cifs/connect.c
diff options
context:
space:
mode:
authorJeff Layton <jlayton@redhat.com>2012-07-02 07:24:25 -0400
committerSteven French <sfrench@w500smf.(none)>2012-07-03 13:54:42 -0400
commitec01d738a1691dfc85b96b9f796020267a7be577 (patch)
tree57b1c6d90c394181c183978e2ed1d69b8b1ef4dc /fs/cifs/connect.c
parente73f843a3235a19de38359c91586e9eadef12238 (diff)
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)>
Diffstat (limited to 'fs/cifs/connect.c')
-rw-r--r--fs/cifs/connect.c9
1 files changed, 3 insertions, 6 deletions
diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 5b3840725d0..0ae86ddf221 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -3495,18 +3495,15 @@ cifs_negotiate_rsize(struct cifs_tcon *tcon, struct smb_vol *pvolume_info)
3495 * MS-CIFS indicates that servers are only limited by the client's 3495 * MS-CIFS indicates that servers are only limited by the client's
3496 * bufsize for reads, testing against win98se shows that it throws 3496 * bufsize for reads, testing against win98se shows that it throws
3497 * INVALID_PARAMETER errors if you try to request too large a read. 3497 * INVALID_PARAMETER errors if you try to request too large a read.
3498 * OS/2 just sends back short reads.
3498 * 3499 *
3499 * If the server advertises a MaxBufferSize of less than one page, 3500 * If the server doesn't advertise CAP_LARGE_READ_X, then assume that
3500 * assume that it also can't satisfy reads larger than that either. 3501 * it can't handle a read request larger than its MaxBufferSize either.
3501 *
3502 * FIXME: Is there a better heuristic for this?
3503 */ 3502 */
3504 if (tcon->unix_ext && (unix_cap & CIFS_UNIX_LARGE_READ_CAP)) 3503 if (tcon->unix_ext && (unix_cap & CIFS_UNIX_LARGE_READ_CAP))
3505 defsize = CIFS_DEFAULT_IOSIZE; 3504 defsize = CIFS_DEFAULT_IOSIZE;
3506 else if (server->capabilities & CAP_LARGE_READ_X) 3505 else if (server->capabilities & CAP_LARGE_READ_X)
3507 defsize = CIFS_DEFAULT_NON_POSIX_RSIZE; 3506 defsize = CIFS_DEFAULT_NON_POSIX_RSIZE;
3508 else if (server->maxBuf >= PAGE_CACHE_SIZE)
3509 defsize = CIFSMaxBufSize;
3510 else 3507 else
3511 defsize = server->maxBuf - sizeof(READ_RSP); 3508 defsize = server->maxBuf - sizeof(READ_RSP);
3512 3509