This is a note to let you know that I've just added the patch titled
nfsd4: fix decoding of compounds across page boundaries
to the 3.10-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:
nfsd4-fix-decoding-of-compounds-across-page-boundaries.patch
and it can be found in the queue-3.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From 247500820ebd02ad87525db5d9b199e5b66f6636 Mon Sep 17 00:00:00 2001
From: "J. Bruce Fields" <bfields@xxxxxxxxxx>
Date: Fri, 21 Jun 2013 11:48:11 -0400
Subject: nfsd4: fix decoding of compounds across page boundaries
From: "J. Bruce Fields" <bfields@xxxxxxxxxx>
commit 247500820ebd02ad87525db5d9b199e5b66f6636 upstream.
A freebsd NFSv4.0 client was getting rare IO errors expanding a tarball.
A network trace showed the server returning BAD_XDR on the final getattr
of a getattr+write+getattr compound. The final getattr started on a
page boundary.
I believe the Linux client ignores errors on the post-write getattr, and
that that's why we haven't seen this before.
Reported-by: Rick Macklem <rmacklem@xxxxxxxxxxx>
Signed-off-by: J. Bruce Fields <bfields@xxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
fs/nfsd/nfs4xdr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -162,8 +162,8 @@ static __be32 *read_buf(struct nfsd4_com
*/
memcpy(p, argp->p, avail);
/* step to next page */
- argp->p = page_address(argp->pagelist[0]);
argp->pagelist++;
+ argp->p = page_address(argp->pagelist[0]);
if (argp->pagelen < PAGE_SIZE) {
argp->end = argp->p + (argp->pagelen>>2);
argp->pagelen = 0;
Patches currently in stable-queue which might be from bfields@xxxxxxxxxx are
queue-3.10/nfsd4-fix-decoding-of-compounds-across-page-boundaries.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html