This is a note to let you know that I've just added the patch titled
cifs: lower default and max wsize to what 2.6.39 can handle
to the 2.6.39-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
cifs-lower-default-and-max-wsize-to-what-2.6.39-can-handle.patch
and it can be found in the queue-2.6.39 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <sta...@kernel.org> know about it.
>From jlay...@redhat.com Mon Aug 1 14:03:24 2011
From: Jeff Layton <jlay...@redhat.com>
Date: Mon, 1 Aug 2011 15:14:16 -0400
Subject: cifs: lower default and max wsize to what 2.6.39 can handle
To: Greg KH <gre...@suse.de>
Cc: sta...@kernel.org, stable-comm...@vger.kernel.org
Message-ID: <20110801151416.1743b...@tlielax.poochiereds.net>
From: Jeff Layton <jlay...@redhat.com>
This patch is intended for 2.6.39-stable kernels only and is needed to
fix a regression introduced in 2.6.39. Prior to 2.6.39, when signing was
enabled on a socket the client only sent single-page writes. This
changed with commit ca83ce3, which made signed and unsigned connections
use the same codepaths for write calls.
This caused a regression when working with windows servers. Windows
machines will reject writes larger than the MaxBufferSize when signing
is active, but do not clear the CAP_LARGE_WRITE_X flag in the protocol
negotiation. The upshot is that when signing is active, windows servers
often reject large writes from the client in 2.6.39.
Because 3.0 adds support for larger wsize values, simply cherry picking
the upstream patches that fix the wsize negotiation isn't sufficient to
fix this issue. We also need to alter the maximum and default values to
something suitable for 2.6.39.
This patch also accounts for the change in field name from sec_mode to
secMode that went into 3.0.
Cc: <sta...@kernel.org> # .39.x: f7910cb: cifs: clean up wsize negotiation and
allow for larger wsize
Cc: <sta...@kernel.org> # .39.x: 1190f6a: cifs: fix wsize negotiation to
respect max buffer size and active signing (try #4)
Signed-off-by: Jeff Layton <jlay...@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gre...@suse.de>
---
fs/cifs/connect.c | 20 ++++----------------
1 file changed, 4 insertions(+), 16 deletions(-)
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2648,16 +2648,8 @@ static void setup_cifs_sb(struct smb_vol
"mount option supported");
}
-/*
- * When the server supports very large writes via POSIX extensions, we can
- * allow up to 2^24-1, minus the size of a WRITE_AND_X header, not including
- * the RFC1001 length.
- *
- * Note that this might make for "interesting" allocation problems during
- * writeback however as we have to allocate an array of pointers for the
- * pages. A 16M write means ~32kb page array with PAGE_CACHE_SIZE == 4096.
- */
-#define CIFS_MAX_WSIZE ((1<<24) - 1 - sizeof(WRITE_REQ) + 4)
+/* Prior to 3.0, cifs couldn't handle writes larger than this */
+#define CIFS_MAX_WSIZE (PAGEVEC_SIZE * PAGE_CACHE_SIZE)
/*
* When the server doesn't allow large posix writes, only allow a wsize of
@@ -2666,12 +2658,8 @@ static void setup_cifs_sb(struct smb_vol
*/
#define CIFS_MAX_RFC1002_WSIZE (128 * 1024 - sizeof(WRITE_REQ) + 4)
-/*
- * The default wsize is 1M. find_get_pages seems to return a maximum of 256
- * pages in a single call. With PAGE_CACHE_SIZE == 4k, this means we can fill
- * a single wsize request with a single call.
- */
-#define CIFS_DEFAULT_WSIZE (1024 * 1024)
+/* Make the default the same as the max */
+#define CIFS_DEFAULT_WSIZE CIFS_MAX_WSIZE
static unsigned int
cifs_negotiate_wsize(struct cifsTconInfo *tcon, struct smb_vol *pvolume_info)
Patches currently in stable-queue which might be from jlay...@redhat.com are
queue-2.6.39/cifs-lower-default-and-max-wsize-to-what-2.6.39-can-handle.patch
queue-2.6.39/cifs-clean-up-wsize-negotiation-and-allow-for-larger-wsize.patch
queue-2.6.39/cifs-fix-wsize-negotiation-to-respect-max-buffer-size-and.patch
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
