Login
[x]
Log in using an account from:
Fedora Account System
Red Hat Associate
Red Hat Customer
Or login using a Red Hat Bugzilla account
Forgot Password
Login:
Hide Forgot
Create an Account
Red Hat Bugzilla – Attachment 294274 Details for
Bug 428720
[RHEL5 U2] Connectathon RHEL5 client to RHEL4 server, Connectathon failure
[?]
New
Simple Search
Advanced Search
My Links
Browse
Requests
Reports
Current State
Search
Tabular reports
Graphical reports
Duplicates
Other Reports
User Changes
Plotly Reports
Bug Status
Bug Severity
Non-Defaults
|
Product Dashboard
Help
Page Help!
Bug Writing Guidelines
What's new
Browser Support Policy
5.0.4.rh83 Release notes
FAQ
Guides index
User guide
Web Services
Contact
Legal
This site requires JavaScript to be enabled to function correctly, please enable it.
[patch]
patch -- when truncating a readdir reply and setting EOF return -EIO
0001-NFS-have-short-READDIR-replies-return-EIO.patch (text/plain), 2.12 KB, created by
Jeff Layton
on 2008-02-07 21:48:02 UTC
(
hide
)
Description:
patch -- when truncating a readdir reply and setting EOF return -EIO
Filename:
MIME Type:
Creator:
Jeff Layton
Created:
2008-02-07 21:48:02 UTC
Size:
2.12 KB
patch
obsolete
>From 836e756c20ab1bd3e7aed0ddc1b7570d64c6cd07 Mon Sep 17 00:00:00 2001 >From: Jeff Layton <jlayton@redhat.com> >Date: Thu, 7 Feb 2008 08:34:22 -0500 >Subject: [PATCH] NFS: have short READDIR replies return -EIO > >Recently, I ran across a server-side bug that caused the server to send >truncated READDIR replies. The server would send a valid RPC response to >a READDIR call, but the contents of it were basically missing >(everything after the status). > >This problem had long been patched in mainline kernels, but the >interesting bit was that newer clients didn't return an error in this >situation. The XDR decoders for readdir calls are supposed to check the >validity of the response, but in this situation it just fudges the >contents of the pagecache to make it look like a completely empty >directory. > >Shouldn't the client return an error in this situation? The response >obviously isn't valid so it seems like it shouldn't pretend that it is. >If so, would the following patch make sense? > >Signed-off-by: Jeff Layton <jlayton@redhat.com> >--- > fs/nfs/nfs2xdr.c | 1 + > fs/nfs/nfs3xdr.c | 1 + > fs/nfs/nfs4xdr.c | 1 + > 3 files changed, 3 insertions(+), 0 deletions(-) > >diff --git a/fs/nfs/nfs2xdr.c b/fs/nfs/nfs2xdr.c >index 1f7ea67..aa6966a 100644 >--- a/fs/nfs/nfs2xdr.c >+++ b/fs/nfs/nfs2xdr.c >@@ -478,6 +478,7 @@ nfs_xdr_readdirres(struct rpc_rqst *req, __be32 *p, void *dummy) > if (!nr) { > dprintk("NFS: readdir reply truncated!\n"); > entry[1] = 1; >+ nr = -errno_NFSERR_IO; > } > goto out; > err_unmap: >diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c >index 3917e2f..04ba525 100644 >--- a/fs/nfs/nfs3xdr.c >+++ b/fs/nfs/nfs3xdr.c >@@ -592,6 +592,7 @@ nfs3_xdr_readdirres(struct rpc_rqst *req, __be32 *p, struct nfs3_readdirres *res > if (!nr) { > dprintk("NFS: readdir reply truncated!\n"); > entry[1] = 1; >+ nr = -errno_NFSERR_IO; > } > goto out; > err_unmap: >diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c >index db1ed9c..139c9e1 100644 >--- a/fs/nfs/nfs4xdr.c >+++ b/fs/nfs/nfs4xdr.c >@@ -3544,6 +3544,7 @@ short_pkt: > if (!nr) { > dprintk("NFS: readdir reply truncated!\n"); > entry[1] = 1; >+ nr = -errno_NFSERR_IO; > } > goto out; > err_unmap: >-- >1.5.3.8 >
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 428720
:
294274
|
303350
|
303352
|
303353