* Memory corruption in nfs3_xdr_setaclargs()
@ 2009-01-20 17:14 Sachin S. Prabhu
2009-01-20 18:15 ` Trond Myklebust
0 siblings, 1 reply; 8+ messages in thread
From: Sachin S. Prabhu @ 2009-01-20 17:14 UTC (permalink / raw)
To: linux-nfs
[-- Attachment #1: Type: text/plain, Size: 2441 bytes --]
A mistake in calculating the space left in the header in nfs3_xdr_setaclargs()
can cause memory corruption when setting a large number of acls.
Reproducer:
On Server:
1) Create directory /test and set mode 777.
mkdir /test; chmod 777 /test
2) Add 200 users and set default acl for user on /test
for i in {1..200}; do echo $i; useradd user$i; setfacl -m d:u:user$i:rwx
/test;done
3) Add export /test in /etc/exports
/test *(rw)
On client
1) Mount server:/test
mount server:/test /mnt
2) Create large number of directories on the the share.
cd/mnt; for i in {1..1000}; do mkdir $i; done
At this point, the client should crash.
A change in call_header changes the value req->rq_snd_buf->head[0]->iov_len to
reflect the exact size of the header.
[PATCH] RPC: Ensure XDR iovec length is initialized correctly in call_header
334ccfd545bba9690515f2c5c167d5adb161989b
The iov_len is set to the size of the header in call_header().
req->rq_slen = xdr_adjust_iovec(&req->rq_svec[0], p);
nfs3_xdr_setaclargs() depends on the older behavior and uses this value when
calculating the number of ACLs it can fit into the header.
/* put as much of the acls into head as possible. */
len_in_head = min_t(unsigned int, buf->head->iov_len - base, len);
len -= len_in_head;
req->rq_slen = xdr_adjust_iovec(req->rq_svec, p + (len_in_head >> 2));
Since at this stage, iov_len < base, len_in_head will always be set to len. For
a large number of ACLs, this will end up over-writing other parts of memory on
the nfs client.
The following patch which set len_in_head to 0 was tested with the reproducer
and was found to fix the problem.
--- fs/nfs/nfs3xdr.c.orig 2009-01-20 15:18:12.000000000 +0000
+++ fs/nfs/nfs3xdr.c 2009-01-20 15:33:45.000000000 +0000
@@ -691,7 +691,10 @@ nfs3_xdr_setaclargs(struct rpc_rqst *req
*p++ = htonl(args->mask);
base = (char *)p - (char *)buf->head->iov_base;
/* put as much of the acls into head as possible. */
- len_in_head = min_t(unsigned int, buf->head->iov_len - base, len);
+ if ( buf->head->iov_len > base )
+ len_in_head = min_t(unsigned int, buf->head->iov_len - base, len);
+ else
+ len_in_head = 0;
len -= len_in_head;
req->rq_slen = xdr_adjust_iovec(req->rq_svec, p + (len_in_head >> 2));
Thanks to Kevin Rudd who did the major legwork here to figure the problem and
create the patch.
Sachin Prabhu
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Memory corruption in nfs3_xdr_setaclargs() 2009-01-20 17:14 Memory corruption in nfs3_xdr_setaclargs() Sachin S. Prabhu @ 2009-01-20 18:15 ` Trond Myklebust [not found] ` <1232475301.7055.14.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org> 0 siblings, 1 reply; 8+ messages in thread From: Trond Myklebust @ 2009-01-20 18:15 UTC (permalink / raw) To: Sachin S. Prabhu; +Cc: linux-nfs On Tue, 2009-01-20 at 17:14 +0000, Sachin S. Prabhu wrote: > A mistake in calculating the space left in the header in nfs3_xdr_setaclargs() > can cause memory corruption when setting a large number of acls. > > Reproducer: > > On Server: > 1) Create directory /test and set mode 777. > mkdir /test; chmod 777 /test > 2) Add 200 users and set default acl for user on /test > for i in {1..200}; do echo $i; useradd user$i; setfacl -m d:u:user$i:rwx > /test;done > 3) Add export /test in /etc/exports > /test *(rw) > > On client > 1) Mount server:/test > mount server:/test /mnt > 2) Create large number of directories on the the share. > cd/mnt; for i in {1..1000}; do mkdir $i; done > At this point, the client should crash. > > A change in call_header changes the value req->rq_snd_buf->head[0]->iov_len to > reflect the exact size of the header. > [PATCH] RPC: Ensure XDR iovec length is initialized correctly in call_header > 334ccfd545bba9690515f2c5c167d5adb161989b > > The iov_len is set to the size of the header in call_header(). > req->rq_slen = xdr_adjust_iovec(&req->rq_svec[0], p); > > nfs3_xdr_setaclargs() depends on the older behavior and uses this value when > calculating the number of ACLs it can fit into the header. > > /* put as much of the acls into head as possible. */ > len_in_head = min_t(unsigned int, buf->head->iov_len - base, len); > len -= len_in_head; > req->rq_slen = xdr_adjust_iovec(req->rq_svec, p + (len_in_head >> 2)); > > Since at this stage, iov_len < base, len_in_head will always be set to len. For > a large number of ACLs, this will end up over-writing other parts of memory on > the nfs client. > > The following patch which set len_in_head to 0 was tested with the reproducer > and was found to fix the problem. > Looks alright. Could you please add a s-o-b line? Cheers Trond > --- fs/nfs/nfs3xdr.c.orig 2009-01-20 15:18:12.000000000 +0000 > +++ fs/nfs/nfs3xdr.c 2009-01-20 15:33:45.000000000 +0000 > @@ -691,7 +691,10 @@ nfs3_xdr_setaclargs(struct rpc_rqst *req > *p++ = htonl(args->mask); > base = (char *)p - (char *)buf->head->iov_base; > /* put as much of the acls into head as possible. */ > - len_in_head = min_t(unsigned int, buf->head->iov_len - base, len); > + if ( buf->head->iov_len > base ) > + len_in_head = min_t(unsigned int, buf->head->iov_len - base, len); > + else > + len_in_head = 0; > len -= len_in_head; > req->rq_slen = xdr_adjust_iovec(req->rq_svec, p + (len_in_head >> 2)); > > Thanks to Kevin Rudd who did the major legwork here to figure the problem and > create the patch. > > Sachin Prabhu > ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <1232475301.7055.14.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>]
* Re: Memory corruption in nfs3_xdr_setaclargs() [not found] ` <1232475301.7055.14.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org> @ 2009-01-21 14:55 ` Sachin S. Prabhu 2009-03-05 16:33 ` Kevin W. Rudd 1 sibling, 0 replies; 8+ messages in thread From: Sachin S. Prabhu @ 2009-01-21 14:55 UTC (permalink / raw) To: Trond Myklebust; +Cc: linux-nfs [-- Attachment #1: Type: text/plain, Size: 2672 bytes --] Trond Myklebust wrote: > On Tue, 2009-01-20 at 17:14 +0000, Sachin S. Prabhu wrote: >> A mistake in calculating the space left in the header in nfs3_xdr_setaclargs() >> can cause memory corruption when setting a large number of acls. >> >> Reproducer: >> >> On Server: >> 1) Create directory /test and set mode 777. >> mkdir /test; chmod 777 /test >> 2) Add 200 users and set default acl for user on /test >> for i in {1..200}; do echo $i; useradd user$i; setfacl -m d:u:user$i:rwx >> /test;done >> 3) Add export /test in /etc/exports >> /test *(rw) >> >> On client >> 1) Mount server:/test >> mount server:/test /mnt >> 2) Create large number of directories on the the share. >> cd/mnt; for i in {1..1000}; do mkdir $i; done >> At this point, the client should crash. >> >> A change in call_header changes the value req->rq_snd_buf->head[0]->iov_len to >> reflect the exact size of the header. >> [PATCH] RPC: Ensure XDR iovec length is initialized correctly in call_header >> 334ccfd545bba9690515f2c5c167d5adb161989b >> >> The iov_len is set to the size of the header in call_header(). >> req->rq_slen = xdr_adjust_iovec(&req->rq_svec[0], p); >> >> nfs3_xdr_setaclargs() depends on the older behavior and uses this value when >> calculating the number of ACLs it can fit into the header. >> >> /* put as much of the acls into head as possible. */ >> len_in_head = min_t(unsigned int, buf->head->iov_len - base, len); >> len -= len_in_head; >> req->rq_slen = xdr_adjust_iovec(req->rq_svec, p + (len_in_head >> 2)); >> >> Since at this stage, iov_len < base, len_in_head will always be set to len. For >> a large number of ACLs, this will end up over-writing other parts of memory on >> the nfs client. >> >> The following patch which set len_in_head to 0 was tested with the reproducer >> and was found to fix the problem. >> > > Looks alright. Could you please add a s-o-b line? > > Cheers > Trond > Signed-off-by: Kevin Rudd <solgato@us.ibm.com> --- fs/nfs/nfs3xdr.c.orig 2009-01-21 13:09:50.000000000 +0000 +++ fs/nfs/nfs3xdr.c 2009-01-21 13:12:11.000000000 +0000 @@ -712,7 +712,10 @@ nfs3_xdr_setaclargs(struct rpc_rqst *req *p++ = htonl(args->mask); base = (char *)p - (char *)buf->head->iov_base; /* put as much of the acls into head as possible. */ - len_in_head = min_t(unsigned int, buf->head->iov_len - base, len); + if ( buf->head->iov_len > base ) + len_in_head = min_t(unsigned int, buf->head->iov_len - base, len); + else + len_in_head = 0; len -= len_in_head; req->rq_slen = xdr_adjust_iovec(req->rq_svec, p + (len_in_head >> 2)); [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 259 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Memory corruption in nfs3_xdr_setaclargs() [not found] ` <1232475301.7055.14.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org> 2009-01-21 14:55 ` Sachin S. Prabhu @ 2009-03-05 16:33 ` Kevin W. Rudd [not found] ` <alpine.LFD.1.10.0903050829420.3949-mupu0Q0mUPfkOmf+N4b0O9FgqiXiwxn+0E9HWUfgJXw@public.gmane.org> 1 sibling, 1 reply; 8+ messages in thread From: Kevin W. Rudd @ 2009-03-05 16:33 UTC (permalink / raw) To: Trond Myklebust; +Cc: linux-nfs On Tue, 20 Jan 2009, Trond Myklebust wrote: > Date: Tue, 20 Jan 2009 13:15:01 -0500 > From: Trond Myklebust <trond.myklebust@fys.uio.no> > To: Sachin S. Prabhu <sprabhu@redhat.com> > Cc: linux-nfs@vger.kernel.org > Subject: Re: Memory corruption in nfs3_xdr_setaclargs() > > On Tue, 2009-01-20 at 17:14 +0000, Sachin S. Prabhu wrote: >> A mistake in calculating the space left in the header in nfs3_xdr_setaclargs() >> can cause memory corruption when setting a large number of acls. >> >> Reproducer: >> >> On Server: >> 1) Create directory /test and set mode 777. >> mkdir /test; chmod 777 /test >> 2) Add 200 users and set default acl for user on /test >> for i in {1..200}; do echo $i; useradd user$i; setfacl -m d:u:user$i:rwx >> /test;done >> 3) Add export /test in /etc/exports >> /test *(rw) >> >> On client >> 1) Mount server:/test >> mount server:/test /mnt >> 2) Create large number of directories on the the share. >> cd/mnt; for i in {1..1000}; do mkdir $i; done >> At this point, the client should crash. >> >> A change in call_header changes the value req->rq_snd_buf->head[0]->iov_len to >> reflect the exact size of the header. >> [PATCH] RPC: Ensure XDR iovec length is initialized correctly in call_header >> 334ccfd545bba9690515f2c5c167d5adb161989b >> >> The iov_len is set to the size of the header in call_header(). >> req->rq_slen = xdr_adjust_iovec(&req->rq_svec[0], p); >> >> nfs3_xdr_setaclargs() depends on the older behavior and uses this value when >> calculating the number of ACLs it can fit into the header. >> >> /* put as much of the acls into head as possible. */ >> len_in_head = min_t(unsigned int, buf->head->iov_len - base, len); >> len -= len_in_head; >> req->rq_slen = xdr_adjust_iovec(req->rq_svec, p + (len_in_head >> 2)); >> >> Since at this stage, iov_len < base, len_in_head will always be set to len. For >> a large number of ACLs, this will end up over-writing other parts of memory on >> the nfs client. >> >> The following patch which set len_in_head to 0 was tested with the reproducer >> and was found to fix the problem. >> > > Looks alright. Could you please add a s-o-b line? > > Cheers > Trond > >> --- fs/nfs/nfs3xdr.c.orig 2009-01-20 15:18:12.000000000 +0000 >> +++ fs/nfs/nfs3xdr.c 2009-01-20 15:33:45.000000000 +0000 >> @@ -691,7 +691,10 @@ nfs3_xdr_setaclargs(struct rpc_rqst *req >> *p++ = htonl(args->mask); >> base = (char *)p - (char *)buf->head->iov_base; >> /* put as much of the acls into head as possible. */ >> - len_in_head = min_t(unsigned int, buf->head->iov_len - base, len); >> + if ( buf->head->iov_len > base ) >> + len_in_head = min_t(unsigned int, buf->head->iov_len - base, len); >> + else >> + len_in_head = 0; >> len -= len_in_head; >> req->rq_slen = xdr_adjust_iovec(req->rq_svec, p + (len_in_head >> 2)); >> >> Thanks to Kevin Rudd who did the major legwork here to figure the problem and >> create the patch. >> >> Sachin Prabhu >> Trond, Do you know what happened to this patch? Given the nasty corruption aspect to the bug, we were expecting to see a fix for this merged into the mainline by now. Thanks -Kevin -- Kevin W. Rudd IBM Global Services - Linux L3 1-800-426-7378, 1-503-578-4161, T/L 775-4161 ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <alpine.LFD.1.10.0903050829420.3949-mupu0Q0mUPfkOmf+N4b0O9FgqiXiwxn+0E9HWUfgJXw@public.gmane.org>]
* Re: Memory corruption in nfs3_xdr_setaclargs() [not found] ` <alpine.LFD.1.10.0903050829420.3949-mupu0Q0mUPfkOmf+N4b0O9FgqiXiwxn+0E9HWUfgJXw@public.gmane.org> @ 2009-03-05 18:53 ` Trond Myklebust [not found] ` <1236279188.13361.30.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org> 0 siblings, 1 reply; 8+ messages in thread From: Trond Myklebust @ 2009-03-05 18:53 UTC (permalink / raw) To: Kevin W. Rudd; +Cc: linux-nfs On Thu, 2009-03-05 at 08:33 -0800, Kevin W. Rudd wrote: > On Tue, 20 Jan 2009, Trond Myklebust wrote: > > > Date: Tue, 20 Jan 2009 13:15:01 -0500 > > From: Trond Myklebust <trond.myklebust@fys.uio.no> > > To: Sachin S. Prabhu <sprabhu@redhat.com> > > Cc: linux-nfs@vger.kernel.org > > Subject: Re: Memory corruption in nfs3_xdr_setaclargs() > > > > On Tue, 2009-01-20 at 17:14 +0000, Sachin S. Prabhu wrote: > >> A mistake in calculating the space left in the header in nfs3_xdr_setaclargs() > >> can cause memory corruption when setting a large number of acls. > >> > >> Reproducer: > >> > >> On Server: > >> 1) Create directory /test and set mode 777. > >> mkdir /test; chmod 777 /test > >> 2) Add 200 users and set default acl for user on /test > >> for i in {1..200}; do echo $i; useradd user$i; setfacl -m d:u:user$i:rwx > >> /test;done > >> 3) Add export /test in /etc/exports > >> /test *(rw) > >> > >> On client > >> 1) Mount server:/test > >> mount server:/test /mnt > >> 2) Create large number of directories on the the share. > >> cd/mnt; for i in {1..1000}; do mkdir $i; done > >> At this point, the client should crash. > >> > >> A change in call_header changes the value req->rq_snd_buf->head[0]->iov_len to > >> reflect the exact size of the header. > >> [PATCH] RPC: Ensure XDR iovec length is initialized correctly in call_header > >> 334ccfd545bba9690515f2c5c167d5adb161989b > >> > >> The iov_len is set to the size of the header in call_header(). > >> req->rq_slen = xdr_adjust_iovec(&req->rq_svec[0], p); > >> > >> nfs3_xdr_setaclargs() depends on the older behavior and uses this value when > >> calculating the number of ACLs it can fit into the header. > >> > >> /* put as much of the acls into head as possible. */ > >> len_in_head = min_t(unsigned int, buf->head->iov_len - base, len); > >> len -= len_in_head; > >> req->rq_slen = xdr_adjust_iovec(req->rq_svec, p + (len_in_head >> 2)); > >> > >> Since at this stage, iov_len < base, len_in_head will always be set to len. For > >> a large number of ACLs, this will end up over-writing other parts of memory on > >> the nfs client. > >> > >> The following patch which set len_in_head to 0 was tested with the reproducer > >> and was found to fix the problem. > >> > > > > Looks alright. Could you please add a s-o-b line? > > > > Cheers > > Trond > > > >> --- fs/nfs/nfs3xdr.c.orig 2009-01-20 15:18:12.000000000 +0000 > >> +++ fs/nfs/nfs3xdr.c 2009-01-20 15:33:45.000000000 +0000 > >> @@ -691,7 +691,10 @@ nfs3_xdr_setaclargs(struct rpc_rqst *req > >> *p++ = htonl(args->mask); > >> base = (char *)p - (char *)buf->head->iov_base; > >> /* put as much of the acls into head as possible. */ > >> - len_in_head = min_t(unsigned int, buf->head->iov_len - base, len); > >> + if ( buf->head->iov_len > base ) > >> + len_in_head = min_t(unsigned int, buf->head->iov_len - base, len); > >> + else > >> + len_in_head = 0; > >> len -= len_in_head; > >> req->rq_slen = xdr_adjust_iovec(req->rq_svec, p + (len_in_head >> 2)); > >> > >> Thanks to Kevin Rudd who did the major legwork here to figure the problem and > >> create the patch. > >> > >> Sachin Prabhu > >> > > Trond, > > Do you know what happened to this patch? Given the nasty corruption > aspect to the bug, we were expecting to see a fix for this merged into > the mainline by now. Going over that particular procedure reveals a number of bugs that all should be fixed. Trying to estimate how many bytes are free in the header is _WRONG_. That memory is allocated with certain assumptions, which are set in the definition of ACL3_setaclargs_sz. In this case, the assumptions appear to be that we will fit a maximum of 5 ACEs in the header. IOW: the real fix for your corruption problem is simply to set len_in_head to 2*(2+5*3). Currently, the patch supplied by Sachin will always set it to zero. Secondly, doing page allocation in the XDR routine is _WRONG_. For one thing, look at the major memory leak which happens if the client needs to resend the request (which can happen every now and again due to a dropped tcp connection, or all the time due to UDP retransmits). Those pages should have been allocated in nfs3_proc_getacl(), and indeed that is where the wretched things are freed. Trond ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <1236279188.13361.30.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>]
* Re: Memory corruption in nfs3_xdr_setaclargs() [not found] ` <1236279188.13361.30.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org> @ 2009-03-05 19:49 ` Kevin W. Rudd [not found] ` <alpine.LFD.1.10.0903051135040.3949-mupu0Q0mUPfkOmf+N4b0O9FgqiXiwxn+0E9HWUfgJXw@public.gmane.org> 0 siblings, 1 reply; 8+ messages in thread From: Kevin W. Rudd @ 2009-03-05 19:49 UTC (permalink / raw) To: Trond Myklebust; +Cc: linux-nfs On Thu, 5 Mar 2009, Trond Myklebust wrote: > Going over that particular procedure reveals a number of bugs that all > should be fixed. So true ;-) > Trying to estimate how many bytes are free in the header is _WRONG_. > That memory is allocated with certain assumptions, which are set in the > definition of ACL3_setaclargs_sz. In this case, the assumptions appear > to be that we will fit a maximum of 5 ACEs in the header. > IOW: the real fix for your corruption problem is simply to set > len_in_head to 2*(2+5*3). Currently, the patch supplied by Sachin will > always set it to zero. Does setting len_in_head to 2*(2+5*3) take into account the header space already consumed? The initial patch was just a quick-n-dirty way of making sure we didn't overwrite the initial buffer, and a mechanism for generating some discussion around the other deficiencies in this procedure. I'll take the blame for it being a quick hack to simply take the heat off for a critical customer situation :) > Secondly, doing page allocation in the XDR routine is _WRONG_. For one > thing, look at the major memory leak which happens if the client needs > to resend the request (which can happen every now and again due to a > dropped tcp connection, or all the time due to UDP retransmits). > Those pages should have been allocated in nfs3_proc_getacl(), and indeed > that is where the wretched things are freed. That's an issue I hadn't noticed, but this isn't really my area of expertice. Thanks for taking a closer look at this area of code. -Kevin ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <alpine.LFD.1.10.0903051135040.3949-mupu0Q0mUPfkOmf+N4b0O9FgqiXiwxn+0E9HWUfgJXw@public.gmane.org>]
* Re: Memory corruption in nfs3_xdr_setaclargs() [not found] ` <alpine.LFD.1.10.0903051135040.3949-mupu0Q0mUPfkOmf+N4b0O9FgqiXiwxn+0E9HWUfgJXw@public.gmane.org> @ 2009-03-06 20:22 ` Trond Myklebust [not found] ` <1236370937.7244.52.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org> 0 siblings, 1 reply; 8+ messages in thread From: Trond Myklebust @ 2009-03-06 20:22 UTC (permalink / raw) To: Kevin W. Rudd; +Cc: linux-nfs [-- Attachment #1: Type: text/plain, Size: 1694 bytes --] On Thu, 2009-03-05 at 11:49 -0800, Kevin W. Rudd wrote: > On Thu, 5 Mar 2009, Trond Myklebust wrote: > > > Going over that particular procedure reveals a number of bugs that all > > should be fixed. > > So true ;-) > > > Trying to estimate how many bytes are free in the header is _WRONG_. > > That memory is allocated with certain assumptions, which are set in the > > definition of ACL3_setaclargs_sz. In this case, the assumptions appear > > to be that we will fit a maximum of 5 ACEs in the header. > > IOW: the real fix for your corruption problem is simply to set > > len_in_head to 2*(2+5*3). Currently, the patch supplied by Sachin will > > always set it to zero. > > Does setting len_in_head to 2*(2+5*3) take into account the > header space already consumed? The initial patch was just a > quick-n-dirty way of making sure we didn't overwrite the initial > buffer, and a mechanism for generating some discussion around the > other deficiencies in this procedure. I'll take the blame for > it being a quick hack to simply take the heat off for a critical > customer situation :) > > > Secondly, doing page allocation in the XDR routine is _WRONG_. For one > > thing, look at the major memory leak which happens if the client needs > > to resend the request (which can happen every now and again due to a > > dropped tcp connection, or all the time due to UDP retransmits). > > Those pages should have been allocated in nfs3_proc_getacl(), and indeed > > that is where the wretched things are freed. > > That's an issue I hadn't noticed, but this isn't really my area of > expertice. Thanks for taking a closer look at this area of code. Does the attached patch help? Trond [-- Attachment #2: Type: application/x-dif, Size: 5542 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <1236370937.7244.52.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>]
* Re: Memory corruption in nfs3_xdr_setaclargs() [not found] ` <1236370937.7244.52.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org> @ 2009-03-06 22:51 ` Kevin W. Rudd 0 siblings, 0 replies; 8+ messages in thread From: Kevin W. Rudd @ 2009-03-06 22:51 UTC (permalink / raw) To: Trond Myklebust; +Cc: linux-nfs On Fri, 6 Mar 2009, Trond Myklebust wrote: > > Does the attached patch help? > > Trond > Yes. No corruption or issues on my large-ACL-list test system. Thanks. -Kevin ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-03-06 22:51 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-20 17:14 Memory corruption in nfs3_xdr_setaclargs() Sachin S. Prabhu
2009-01-20 18:15 ` Trond Myklebust
[not found] ` <1232475301.7055.14.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-01-21 14:55 ` Sachin S. Prabhu
2009-03-05 16:33 ` Kevin W. Rudd
[not found] ` <alpine.LFD.1.10.0903050829420.3949-mupu0Q0mUPfkOmf+N4b0O9FgqiXiwxn+0E9HWUfgJXw@public.gmane.org>
2009-03-05 18:53 ` Trond Myklebust
[not found] ` <1236279188.13361.30.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-03-05 19:49 ` Kevin W. Rudd
[not found] ` <alpine.LFD.1.10.0903051135040.3949-mupu0Q0mUPfkOmf+N4b0O9FgqiXiwxn+0E9HWUfgJXw@public.gmane.org>
2009-03-06 20:22 ` Trond Myklebust
[not found] ` <1236370937.7244.52.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-03-06 22:51 ` Kevin W. Rudd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox