linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: Olga Kornievskaia <kolga@netapp.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v1] NFS: Fix handling of reply page vector
Date: Mon, 8 Apr 2019 16:58:13 -0400	[thread overview]
Message-ID: <B28ACEA4-BB35-4137-A81F-50A1D2974F6A@oracle.com> (raw)
In-Reply-To: <bede7559be11f283e9f37db2da0b47ddf869a468.camel@hammerspace.com>



> On Apr 8, 2019, at 4:38 PM, Trond Myklebust <trondmy@hammerspace.com> wrote:
> 
> On Mon, 2019-04-08 at 16:00 -0400, Chuck Lever wrote:
>> NFSv4 GETACL and FS_LOCATIONS requests stopped working in v5.1-rc.
>> 
>> These two need the extra padding to be added directly to the reply
>> length.
>> 
>> Reported-by: Olga Kornievskaia <aglo@umich.edu>
>> Fixes: 02ef04e432ba ("NFS: Account for XDR pad of buf->pages")
>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>> ---
>> fs/nfs/nfs4xdr.c |    4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/fs/nfs/nfs4xdr.c b/fs/nfs/nfs4xdr.c
>> index cfcabc3..6024461 100644
>> --- a/fs/nfs/nfs4xdr.c
>> +++ b/fs/nfs/nfs4xdr.c
>> @@ -2589,7 +2589,7 @@ static void nfs4_xdr_enc_getacl(struct rpc_rqst
>> *req, struct xdr_stream *xdr,
>> 			ARRAY_SIZE(nfs4_acl_bitmap), &hdr);
>> 
>> 	rpc_prepare_reply_pages(req, args->acl_pages, 0,
>> -				args->acl_len, replen);
>> +				args->acl_len, replen + 1);
>> 	encode_nops(&hdr);
>> }
>> 
>> @@ -2811,7 +2811,7 @@ static void nfs4_xdr_enc_fs_locations(struct
>> rpc_rqst *req,
>> 	}
>> 
>> 	rpc_prepare_reply_pages(req, (struct page **)&args->page, 0,
>> -				PAGE_SIZE, replen);
>> +				PAGE_SIZE, replen + 1);
>> 	encode_nops(&hdr);
>> }
>> 
> 
> I'm having trouble with the math here. Why are we pre-emptively
> subtracting a word from the tail? The header constants are always 4-bit 
> aligned because they are calculated as a word count, so I'm not
> understanding why we need commit 02ef04e432ba at all.
> 
> Can you please explain, Chuck?

The goal is to allocate a reply buffer that is just large enough
to fit the expected reply, and ensure that the variable-length
payload will start exactly where the xdr_buf's pages begin.

In cases where the payload length is not aligned to four bytes,
an extra quad has to be allocated in the tail. So, the total
reply length is increased by one quad so there is enough space
for the XDR pad bytes in the tail.


--
Chuck Lever




  reply	other threads:[~2019-04-08 20:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-08 20:00 [PATCH v1] NFS: Fix handling of reply page vector Chuck Lever
2019-04-08 20:22 ` Olga Kornievskaia
2019-04-08 20:38 ` Trond Myklebust
2019-04-08 20:58   ` Chuck Lever [this message]
2019-04-08 21:23     ` Trond Myklebust
2019-04-08 21:29       ` Chuck Lever

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=B28ACEA4-BB35-4137-A81F-50A1D2974F6A@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=kolga@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@hammerspace.com \
    /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;
as well as URLs for NNTP newsgroup(s).