Linux NFS development
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: chuck.lever@oracle.com
Cc: linux-nfs@vger.kernel.org, nfsv4@linux-nfs.org
Subject: Re: [PATCH 2/3] NFS: clean up short packet handling for NFSv3 readdir
Date: Fri, 22 Feb 2008 16:26:56 -0500	[thread overview]
Message-ID: <20080222162656.37dfd82a@tleilax.poochiereds.net> (raw)
In-Reply-To: <47BF3A70.4040409@oracle.com>

On Fri, 22 Feb 2008 16:11:12 -0500
Chuck Lever <chuck.lever@oracle.com> wrote:

> Hi Jeff-
> 
> For NFSv3, is the READDIRPLUS decoder affected as well?
> 

Yes. READDIR and READDIRPLUS use the same decoder routine, so this patch
should also make short READDIRPLUS packets return an error using the
same set of rules.

> Jeff Layton wrote:
> > Currently, the NFS readdir decoders have a workaround for buggy servers
> > that send an empty readdir response with the EOF bit unset. If the
> > server sends a malformed response in some cases, this workaround kicks
> > in and just returns an empty response rather than returning a proper
> > error to the caller.
> > 
> > This patch does 3 things:
> > 
> > 1) have malformed responses with no entries return error (-EIO)
> > 
> > 2) preserve existing workaround for servers that send empty
> >    responses with the EOF marker unset.
> > 
> > 3) Add some comments to clarify the logic in nfs3_xdr_readdirres().
> > 
> > Signed-off-by: Jeff Layton <jlayton@redhat.com>
> > ---
> >  fs/nfs/nfs3xdr.c |   37 ++++++++++++++++++++++++++++---------
> >  1 files changed, 28 insertions(+), 9 deletions(-)
> > 
> > diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
> > index 3917e2f..fb03048 100644
> > --- a/fs/nfs/nfs3xdr.c
> > +++ b/fs/nfs/nfs3xdr.c
> > @@ -508,7 +508,7 @@ nfs3_xdr_readdirres(struct rpc_rqst *req, __be32 *p, struct nfs3_readdirres *res
> >  	struct page **page;
> >  	size_t hdrlen;
> >  	u32 len, recvd, pglen;
> > -	int status, nr;
> > +	int status, nr = 0;
> >  	__be32 *entry, *end, *kaddr;
> >  
> >  	status = ntohl(*p++);
> > @@ -542,7 +542,12 @@ nfs3_xdr_readdirres(struct rpc_rqst *req, __be32 *p, struct nfs3_readdirres *res
> >  	kaddr = p = kmap_atomic(*page, KM_USER0);
> >  	end = (__be32 *)((char *)p + pglen);
> >  	entry = p;
> > -	for (nr = 0; *p++; nr++) {
> > +
> > +	/* Make sure the packet actually has a value_follows and EOF entry */
> > +	if ((entry + 1) > end)
> > +		goto short_pkt;
> > +
> > +	for (; *p++; nr++) {
> >  		if (p + 3 > end)
> >  			goto short_pkt;
> >  		p += 2;				/* inode # */
> > @@ -581,18 +586,32 @@ nfs3_xdr_readdirres(struct rpc_rqst *req, __be32 *p, struct nfs3_readdirres *res
> >  			goto short_pkt;
> >  		entry = p;
> >  	}
> > -	if (!nr && (entry[0] != 0 || entry[1] == 0))
> > -		goto short_pkt;
> > +
> > +	/*
> > +	 * Apparently some server sends responses that are a valid size, but
> > +	 * contain no entries, and have value_follows==0 and EOF==0. For
> > +	 * those, just set the EOF marker.
> > +	 */
> > +	if (!nr && entry[1] == 0) {
> > +		dprintk("NFS: readdir reply truncated!\n");
> > +		entry[1] = 1;
> > +	}
> >   out:
> >  	kunmap_atomic(kaddr, KM_USER0);
> >  	return nr;
> >   short_pkt:
> > +	/*
> > +	 * When we get a short packet there are 2 possibilities. We can
> > +	 * return an error, or fix up the response to look like a valid
> > +	 * response and return what we have so far. If there are no
> > +	 * entries and the packet was short, then return -EIO. If there
> > +	 * are valid entries in the response, return them and pretend that
> > +	 * the call was successful, but incomplete. The caller can retry the
> > +	 * readdir starting at the last cookie.
> > +	 */
> >  	entry[0] = entry[1] = 0;
> > -	/* truncate listing ? */
> > -	if (!nr) {
> > -		dprintk("NFS: readdir reply truncated!\n");
> > -		entry[1] = 1;
> > -	}
> > +	if (!nr)
> > +		nr = -errno_NFSERR_IO;
> >  	goto out;
> >  err_unmap:
> >  	nr = -errno_NFSERR_IO;


-- 
Jeff Layton <jlayton@redhat.com>

      reply	other threads:[~2008-02-22 21:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-22 19:49 [PATCH 0/3] Should truncated READDIR replies return -EIO? Jeff Layton
2008-02-22 19:49 ` [PATCH 1/3] NFS: clean up short packet handling for NFSv2 readdir Jeff Layton
2008-02-22 19:50   ` [PATCH 2/3] NFS: clean up short packet handling for NFSv3 readdir Jeff Layton
2008-02-22 19:50     ` [PATCH 3/3] NFS: clean up short packet handling for NFSv4 readdir Jeff Layton
2008-02-22 21:11     ` [PATCH 2/3] NFS: clean up short packet handling for NFSv3 readdir Chuck Lever
2008-02-22 21:26       ` Jeff Layton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080222162656.37dfd82a@tleilax.poochiereds.net \
    --to=jlayton@redhat.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=nfsv4@linux-nfs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox