[PATCH] NFS: Fix send buffer length calculation in nfs3_xdr_setaclargs()

[PATCH] NFS: Fix send buffer length calculation in nfs3_xdr_setaclargs()

[Suresh Jayaraman]

The recent posixacl fix(commit ae46141ff08f1965b17c531b571953c39ce8b9e2)
seems to have introduced a bug that will lead to -EINVAL errors during
normal setfacl operations on file or dir. This patch attempts to fix
this.

Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
---

diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index e6a1932..7cd0069 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -702,18 +702,19 @@ nfs3_xdr_setaclargs(struct rpc_rqst *req, __be32 *p,
                    struct nfs3_setaclargs *args)
 {
 	struct xdr_buf *buf = &req->rq_snd_buf;
-	unsigned int base;
+	unsigned int base, len;
+	unsigned int len_in_head = 2 * (2 + 3 * NFS_ACL_MAX_ENTRIES_INLINE);
 	int err;
 
 	p = xdr_encode_fhandle(p, NFS_FH(args->inode));
 	*p++ = htonl(args->mask);
-	req->rq_slen = xdr_adjust_iovec(req->rq_svec, p);
-	base = req->rq_slen;
+	len = xdr_adjust_iovec(req->rq_svec, p);
+	base = len;
+	len -= len_in_head; 
+	req->rq_slen = xdr_adjust_iovec(req->rq_svec, p + (len >> 2));
 
 	if (args->npages != 0)
-		xdr_encode_pages(buf, args->pages, 0, args->len);
-	else
-		req->rq_slen += args->len;
+		xdr_encode_pages(buf, args->pages, 0, len);
 
 	err = nfsacl_encode(buf, base, args->inode,
 			    (args->mask & NFS_ACL) ?

Re: [PATCH] NFS: Fix send buffer length calculation in nfs3_xdr_setaclargs()

[Trond Myklebust]

On Wed, 2009-04-15 at 19:40 +0530, Suresh Jayaraman wrote:
> The recent posixacl fix(commit ae46141ff08f1965b17c531b571953c39ce8b9e2)
> seems to have introduced a bug that will lead to -EINVAL errors during
> normal setfacl operations on file or dir. This patch attempts to fix
> this.

To start with, your len_in_head is in units of 32-bit _words_, whereas
len, base, and req->rq_slen are in units of bytes.

Then, 'len' is initialised to the length of the currently encoded part
of the RPC header before subtracting 'len_in_head'. The resulting number
is then used both as the length of the page array, and to extend the
length of the req->rq_svec??? That makes absolutely no sense...


Please check if the following patch fixes things for you.

Trond
------------------------------------------------------------
>From b273b42f8b793a4a446015b50a5c1473553af48b Mon Sep 17 00:00:00 2001
From: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Wed, 15 Apr 2009 13:58:45 -0400
Subject: [PATCH] NFS: Fix the XDR iovec calculation in nfs3_xdr_setaclargs

Commit ae46141ff08f1965b17c531b571953c39ce8b9e2 (NFSv3: Fix posix ACL code)
introduces a bug in the calculation of the XDR header iovec. In the case
where we are inlining the acls, we need to adjust the length of the iovec
req->rq_svec, in addition to adjusting the total buffer length.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
 fs/nfs/nfs3xdr.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index e6a1932..35869a4 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -713,7 +713,8 @@ nfs3_xdr_setaclargs(struct rpc_rqst *req, __be32 *p,
 	if (args->npages != 0)
 		xdr_encode_pages(buf, args->pages, 0, args->len);
 	else
-		req->rq_slen += args->len;
+		req->rq_slen = xdr_adjust_iovec(req->rq_svec,
+				p + XDR_QUADLEN(args->len));
 
 	err = nfsacl_encode(buf, base, args->inode,
 			    (args->mask & NFS_ACL) ?
-- 
1.6.0.4


-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: [PATCH] NFS: Fix send buffer length calculation in nfs3_xdr_setaclargs()

[Leonardo Chiquitto]

> Please check if the following patch fixes things for you.
>
> Trond
> ------------------------------------------------------------
> >From b273b42f8b793a4a446015b50a5c1473553af48b Mon Sep 17 00:00:00 2001
> From: Trond Myklebust <Trond.Myklebust@netapp.com>
> Date: Wed, 15 Apr 2009 13:58:45 -0400
> Subject: [PATCH] NFS: Fix the XDR iovec calculation in nfs3_xdr_setaclargs
>
> Commit ae46141ff08f1965b17c531b571953c39ce8b9e2 (NFSv3: Fix posix ACL code)
> introduces a bug in the calculation of the XDR header iovec. In the case
> where we are inlining the acls, we need to adjust the length of the iovec
> req->rq_svec, in addition to adjusting the total buffer length.
>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

I just tested and it fixes the problem for me.

Thanks!
Leonardo

Re: [PATCH] NFS: Fix send buffer length calculation in nfs3_xdr_setaclargs()

[Suresh Jayaraman]

Trond Myklebust wrote:
> On Wed, 2009-04-15 at 19:40 +0530, Suresh Jayaraman wrote:
>> The recent posixacl fix(commit ae46141ff08f1965b17c531b571953c39ce8b9e2)
>> seems to have introduced a bug that will lead to -EINVAL errors during
>> normal setfacl operations on file or dir. This patch attempts to fix
>> this.
> 
> To start with, your len_in_head is in units of 32-bit _words_, whereas
> len, base, and req->rq_slen are in units of bytes.
> 
> Then, 'len' is initialised to the length of the currently encoded part
> of the RPC header before subtracting 'len_in_head'. The resulting number

Doh, I got it wrong totally. Thanks for the explaination.

On a side note, I think it would be nice to add little comments in xdr
code to explain non-obvious pieces.

> 
> Please check if the following patch fixes things for you.

Yes, the below patch fixes the issue for me too.

Thanks,

> Trond
> ------------------------------------------------------------
>>From b273b42f8b793a4a446015b50a5c1473553af48b Mon Sep 17 00:00:00 2001
> From: Trond Myklebust <Trond.Myklebust@netapp.com>
> Date: Wed, 15 Apr 2009 13:58:45 -0400
> Subject: [PATCH] NFS: Fix the XDR iovec calculation in nfs3_xdr_setaclargs
> 
> Commit ae46141ff08f1965b17c531b571953c39ce8b9e2 (NFSv3: Fix posix ACL code)
> introduces a bug in the calculation of the XDR header iovec. In the case
> where we are inlining the acls, we need to adjust the length of the iovec
> req->rq_svec, in addition to adjusting the total buffer length.
> 
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
> ---
>  fs/nfs/nfs3xdr.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
> index e6a1932..35869a4 100644
> --- a/fs/nfs/nfs3xdr.c
> +++ b/fs/nfs/nfs3xdr.c
> @@ -713,7 +713,8 @@ nfs3_xdr_setaclargs(struct rpc_rqst *req, __be32 *p,
>  	if (args->npages != 0)
>  		xdr_encode_pages(buf, args->pages, 0, args->len);
>  	else
> -		req->rq_slen += args->len;
> +		req->rq_slen = xdr_adjust_iovec(req->rq_svec,
> +				p + XDR_QUADLEN(args->len));
>  
>  	err = nfsacl_encode(buf, base, args->inode,
>  			    (args->mask & NFS_ACL) ?


-- 
Suresh Jayaraman

Re: [PATCH] NFS: Fix send buffer length calculation in nfs3_xdr_setaclargs()

[Chuck Lever]

On Apr 16, 2009, at 1:17 AM, Suresh Jayaraman wrote:
> Trond Myklebust wrote:
>> On Wed, 2009-04-15 at 19:40 +0530, Suresh Jayaraman wrote:
>>> The recent posixacl fix(commit  
>>> ae46141ff08f1965b17c531b571953c39ce8b9e2)
>>> seems to have introduced a bug that will lead to -EINVAL errors  
>>> during
>>> normal setfacl operations on file or dir. This patch attempts to fix
>>> this.
>>
>> To start with, your len_in_head is in units of 32-bit _words_,  
>> whereas
>> len, base, and req->rq_slen are in units of bytes.
>>
>> Then, 'len' is initialised to the length of the currently encoded  
>> part
>> of the RPC header before subtracting 'len_in_head'. The resulting  
>> number
>
> Doh, I got it wrong totally. Thanks for the explaination.
>
> On a side note, I think it would be nice to add little comments in xdr
> code to explain non-obvious pieces.

As an aside, I think implementing this with xdr_streams might have  
some clarity benefits.

>> Please check if the following patch fixes things for you.
>
> Yes, the below patch fixes the issue for me too.
>
> Thanks,
>
>> Trond
>> ------------------------------------------------------------
>>> From b273b42f8b793a4a446015b50a5c1473553af48b Mon Sep 17 00:00:00  
>>> 2001
>> From: Trond Myklebust <Trond.Myklebust@netapp.com>
>> Date: Wed, 15 Apr 2009 13:58:45 -0400
>> Subject: [PATCH] NFS: Fix the XDR iovec calculation in  
>> nfs3_xdr_setaclargs
>>
>> Commit ae46141ff08f1965b17c531b571953c39ce8b9e2 (NFSv3: Fix posix  
>> ACL code)
>> introduces a bug in the calculation of the XDR header iovec. In the  
>> case
>> where we are inlining the acls, we need to adjust the length of the  
>> iovec
>> req->rq_svec, in addition to adjusting the total buffer length.
>>
>> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
>> ---
>> fs/nfs/nfs3xdr.c |    3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
>> index e6a1932..35869a4 100644
>> --- a/fs/nfs/nfs3xdr.c
>> +++ b/fs/nfs/nfs3xdr.c
>> @@ -713,7 +713,8 @@ nfs3_xdr_setaclargs(struct rpc_rqst *req,  
>> __be32 *p,
>> 	if (args->npages != 0)
>> 		xdr_encode_pages(buf, args->pages, 0, args->len);
>> 	else
>> -		req->rq_slen += args->len;
>> +		req->rq_slen = xdr_adjust_iovec(req->rq_svec,
>> +				p + XDR_QUADLEN(args->len));
>>
>> 	err = nfsacl_encode(buf, base, args->inode,
>> 			    (args->mask & NFS_ACL) ?
>
>
> -- 
> Suresh Jayaraman
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs"  
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: [PATCH] NFS: Fix send buffer length calculation in nfs3_xdr_setaclargs()

[Trond Myklebust]

On Thu, 2009-04-16 at 09:52 -0400, Chuck Lever wrote:
> On Apr 16, 2009, at 1:17 AM, Suresh Jayaraman wrote:
> > Trond Myklebust wrote:
> >> On Wed, 2009-04-15 at 19:40 +0530, Suresh Jayaraman wrote:
> >>> The recent posixacl fix(commit  
> >>> ae46141ff08f1965b17c531b571953c39ce8b9e2)
> >>> seems to have introduced a bug that will lead to -EINVAL errors  
> >>> during
> >>> normal setfacl operations on file or dir. This patch attempts to fix
> >>> this.
> >>
> >> To start with, your len_in_head is in units of 32-bit _words_,  
> >> whereas
> >> len, base, and req->rq_slen are in units of bytes.
> >>
> >> Then, 'len' is initialised to the length of the currently encoded  
> >> part
> >> of the RPC header before subtracting 'len_in_head'. The resulting  
> >> number
> >
> > Doh, I got it wrong totally. Thanks for the explaination.
> >
> > On a side note, I think it would be nice to add little comments in xdr
> > code to explain non-obvious pieces.
> 
> As an aside, I think implementing this with xdr_streams might have  
> some clarity benefits.

Possibly, but right now, I just want to merge the one-liner fix into
2.6.30-rc2 and 2.6.29-stable...

Cheers
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: [PATCH] NFS: Fix send buffer length calculation in nfs3_xdr_setaclargs()

[Chuck Lever]

On Apr 16, 2009, at 12:42 PM, Trond Myklebust wrote:
> On Thu, 2009-04-16 at 09:52 -0400, Chuck Lever wrote:
>> On Apr 16, 2009, at 1:17 AM, Suresh Jayaraman wrote:
>>> Trond Myklebust wrote:
>>>> On Wed, 2009-04-15 at 19:40 +0530, Suresh Jayaraman wrote:
>>>>> The recent posixacl fix(commit
>>>>> ae46141ff08f1965b17c531b571953c39ce8b9e2)
>>>>> seems to have introduced a bug that will lead to -EINVAL errors
>>>>> during
>>>>> normal setfacl operations on file or dir. This patch attempts to  
>>>>> fix
>>>>> this.
>>>>
>>>> To start with, your len_in_head is in units of 32-bit _words_,
>>>> whereas
>>>> len, base, and req->rq_slen are in units of bytes.
>>>>
>>>> Then, 'len' is initialised to the length of the currently encoded
>>>> part
>>>> of the RPC header before subtracting 'len_in_head'. The resulting
>>>> number
>>>
>>> Doh, I got it wrong totally. Thanks for the explaination.
>>>
>>> On a side note, I think it would be nice to add little comments in  
>>> xdr
>>> code to explain non-obvious pieces.
>>
>> As an aside, I think implementing this with xdr_streams might have
>> some clarity benefits.
>
> Possibly, but right now, I just want to merge the one-liner fix into
> 2.6.30-rc2 and 2.6.29-stable...

No rush, just a suggestion.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com