* [NFS BUG] Resoruces leak caused by commit - NFS: Don't use vm_map_ram() in readdir (55ea499d60aefa3d03a77fc8590c26b5881faa92)
@ 2011-03-21 16:53 Jacek Luczak
2011-03-21 17:05 ` Trond Myklebust
0 siblings, 1 reply; 3+ messages in thread
From: Jacek Luczak @ 2011-03-21 16:53 UTC (permalink / raw)
To: Trond.Myklebust, mkl, gregkh; +Cc: LKML
Hi,
*BRIEF*: Reading lot of files from nfs mounted on directory lead to a
resources leak. Affected Kernels: 2.6.37.1-2.6.37.4, did not tested on
2.6.38 (assume that issue is also there).
Steps to reproduce:
1) cd /some/nfs/mounted/dir
2) find . –type f | wc –l
On healthy system this will give a number of files below the dir - in
my test env. this gives 692 files. On broken system after a while when
whole memory will be consumed this will throw:
find: memory exhausted
Reproduced same with rsync to local storage:
sending incremental file list
[sender] expand file_list pointer array to 524288 bytes, did move
[sender] expand file_list pointer array to 1048576 bytes, did move
[sender] expand file_list pointer array to 2097152 bytes, did move
[sender] expand file_list pointer array to 4194304 bytes, did move
[sender] expand file_list pointer array to 8388608 bytes, did move
[sender] expand file_list pointer array to 16777216 bytes, did move
[sender] expand file_list pointer array to 33554432 bytes, did move
[sender] expand file_list pointer array to 67108864 bytes, did move
[sender] expand file_list pointer array to 134217728 bytes, did move
[sender] expand file_list pointer array to 268435456 bytes, did move
[sender] expand file_list pointer array to 402653184 bytes, did move
[sender] expand file_list pointer array to 536870912 bytes, did move
[sender] expand file_list pointer array to 671088640 bytes, did move
[sender] expand file_list pointer array to 805306368 bytes, did move
[sender] expand file_list pointer array to 939524096 bytes, did move
[sender] expand file_list pointer array to 1073741824 bytes, did move
Same results as with find – memory consumption bumps to all available space.
Bisected this down to commit:
55ea499d60aefa3d03a77fc8590c26b5881faa92 is the first bad commit
commit 55ea499d60aefa3d03a77fc8590c26b5881faa92
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Sat Jan 8 17:45:38 2011 -0500
NFS: Don't use vm_map_ram() in readdir
commit 6650239a4b01077e80d5a4468562756d77afaa59 upstream.
vm_map_ram() is not available on NOMMU platforms, and causes trouble
on incoherrent architectures such as ARM when we access the page data
through both the direct and the virtual mapping.
The alternative is to use the direct mapping to access page data
for the case when we are not crossing a page boundary, but to copy
the data into a linear scratch buffer when we are accessing data
that spans page boundaries.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
:040000 040000 b8416029d026cd8e43d6517bcce32ea86180d31a
49dd8041519101ab68075b502ad18127f6ab86d4 M fs
:040000 040000 9332a8f43f88b80dd11d76da0e35bfdfe345798f
71b519dd4ce6fe70a9ecaa1e068bc56ea7c0cd4e M include
:040000 040000 d4f45b70708f5d238eacececb9459c7a88d8ec77
f70bedd7247a37e14972448f5f1803edc1440fc4 M net
Reverting this commit fixes this issue.
I did not find any record that could lead to similar issue.
-Jacek
BTW: Below you can see results of tracing find process stat in time
(interval 5s), one can see that memory is consumed realllly fast:
4632 (find) R 3978 4632 3978 34818 4632 4202496 928598 0 0 0 800 520 0
0 20 0 1 0 43434 6509740032 928407 18446744073709551615 4194304
4345760 1407370072175
68 140737007214080 222122567691 0 0 0 0 0 0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 1287947 0 0 0 1120 700
0 0 20 0 1 0 43434 6509740032 1287777 18446744073709551615 4194304
4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0 0 0 17
12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 1647203 0 0 0 1432 886
0 0 20 0 1 0 43434 8657223680 1647015 18446744073709551615 4194304
4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0 0 0 17
12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 1995616 0 0 0 1726
1092 0 0 20 0 1 0 43434 12952190976 1995445 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 2349570 0 0 0 2037
1282 0 0 20 0 1 0 43434 12952190976 2349403 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122458887 0 0 0 0 0
0 0 17 13 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 2714736 0 0 0 2346
1472 0 0 20 0 1 0 43434 12952190976 2714581 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 13 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 3067401 0 0 0 2654
1665 0 0 20 0 1 0 43434 17247158272 3067256 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 13 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 3429996 0 0 0 2957
1862 0 0 20 0 1 0 43434 25837092864 3429860 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 13 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 3792783 0 0 0 3267
2052 0 0 20 0 1 0 43434 25837092864 3792596 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 13 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 4155928 0 0 0 3577
2242 0 0 20 0 1 0 43434 25837092864 4155794 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 13 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 4510661 0 0 0 3891
2428 0 0 20 0 1 0 43434 25837092864 4510478 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 4869840 0 0 0 4206
2612 0 0 20 0 1 0 43434 25837092864 4869650 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 5229534 0 0 0 4511
2807 0 0 20 0 1 0 43434 25837092864 5229350 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 5569911 0 0 0 4810
3009 0 0 20 0 1 0 43434 34427027456 5569714 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 5934627 0 0 0 5121
3197 0 0 20 0 1 0 43434 34427027456 5934430 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 6299054 0 0 0 5441
3377 0 0 20 0 1 0 43434 34427027456 6298882 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 6663125 0 0 0 5761
3557 0 0 20 0 1 0 43434 34427027456 6662938 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 6982069 0 0 0 6031
3787 0 0 20 0 1 0 43434 51606896640 6981906 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 7344531 0 0 0 6357
3961 0 0 20 0 1 0 43434 51606896640 7344378 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122458890 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 7702709 0 0 0 6670
4148 0 0 20 0 1 0 43434 51606896640 7702560 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 8057531 0 0 0 6998
4319 0 0 20 0 1 0 43434 51606896640 8057376 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 8420823 0 0 0 7303
4514 0 0 20 0 1 0 43434 51606896640 8420640 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 8784294 0 0 0 7607
4709 0 0 20 0 1 0 43434 51606896640 8784102 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 9147287 0 0 0 7904
4913 0 0 20 0 1 0 43434 51606896640 9147102 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 9509736 0 0 0 8212
5104 0 0 20 0 1 0 43434 51606896640 9509574 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 9872277 0 0 0 8521
5295 0 0 20 0 1 0 43434 51606896640 9872112 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 10234354 0 0 0 8840
5475 0 0 20 0 1 0 43434 51606896640 10234188 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 10596443 0 0 0 9158
5658 0 0 20 0 1 0 43434 51606896640 10596264 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122567691 0 0 0 0 0
0 0 17 12 0 0 0 0 0
4632 (find) R 3978 4632 3978 34818 4632 4202496 10958728 0 0 0 9463
5852 0 0 20 0 1 0 43434 51606896640 10958538 18446744073709551615
4194304 4345760 140737007217568 140737007214080 222122458890 0 0 0 0 0
0 0 17 12 0 0 0 0 0
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [NFS BUG] Resoruces leak caused by commit - NFS: Don't use vm_map_ram() in readdir (55ea499d60aefa3d03a77fc8590c26b5881faa92)
2011-03-21 16:53 [NFS BUG] Resoruces leak caused by commit - NFS: Don't use vm_map_ram() in readdir (55ea499d60aefa3d03a77fc8590c26b5881faa92) Jacek Luczak
@ 2011-03-21 17:05 ` Trond Myklebust
2011-03-21 19:47 ` Jacek Luczak
0 siblings, 1 reply; 3+ messages in thread
From: Trond Myklebust @ 2011-03-21 17:05 UTC (permalink / raw)
To: Jacek Luczak; +Cc: mkl, gregkh, LKML
[-- Attachment #1: Type: text/plain, Size: 3534 bytes --]
On Mon, 2011-03-21 at 17:53 +0100, Jacek Luczak wrote:
> Hi,
>
> *BRIEF*: Reading lot of files from nfs mounted on directory lead to a
> resources leak. Affected Kernels: 2.6.37.1-2.6.37.4, did not tested on
> 2.6.38 (assume that issue is also there).
>
> Steps to reproduce:
> 1) cd /some/nfs/mounted/dir
> 2) find . –type f | wc –l
> On healthy system this will give a number of files below the dir - in
> my test env. this gives 692 files. On broken system after a while when
> whole memory will be consumed this will throw:
> find: memory exhausted
>
> Reproduced same with rsync to local storage:
> sending incremental file list
> [sender] expand file_list pointer array to 524288 bytes, did move
> [sender] expand file_list pointer array to 1048576 bytes, did move
> [sender] expand file_list pointer array to 2097152 bytes, did move
> [sender] expand file_list pointer array to 4194304 bytes, did move
> [sender] expand file_list pointer array to 8388608 bytes, did move
> [sender] expand file_list pointer array to 16777216 bytes, did move
> [sender] expand file_list pointer array to 33554432 bytes, did move
> [sender] expand file_list pointer array to 67108864 bytes, did move
> [sender] expand file_list pointer array to 134217728 bytes, did move
> [sender] expand file_list pointer array to 268435456 bytes, did move
> [sender] expand file_list pointer array to 402653184 bytes, did move
> [sender] expand file_list pointer array to 536870912 bytes, did move
> [sender] expand file_list pointer array to 671088640 bytes, did move
> [sender] expand file_list pointer array to 805306368 bytes, did move
> [sender] expand file_list pointer array to 939524096 bytes, did move
> [sender] expand file_list pointer array to 1073741824 bytes, did move
> Same results as with find – memory consumption bumps to all available space.
>
> Bisected this down to commit:
> 55ea499d60aefa3d03a77fc8590c26b5881faa92 is the first bad commit
> commit 55ea499d60aefa3d03a77fc8590c26b5881faa92
> Author: Trond Myklebust <Trond.Myklebust@netapp.com>
> Date: Sat Jan 8 17:45:38 2011 -0500
>
> NFS: Don't use vm_map_ram() in readdir
>
> commit 6650239a4b01077e80d5a4468562756d77afaa59 upstream.
>
> vm_map_ram() is not available on NOMMU platforms, and causes trouble
> on incoherrent architectures such as ARM when we access the page data
> through both the direct and the virtual mapping.
>
> The alternative is to use the direct mapping to access page data
> for the case when we are not crossing a page boundary, but to copy
> the data into a linear scratch buffer when we are accessing data
> that spans page boundaries.
>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
> Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>
> :040000 040000 b8416029d026cd8e43d6517bcce32ea86180d31a
> 49dd8041519101ab68075b502ad18127f6ab86d4 M fs
> :040000 040000 9332a8f43f88b80dd11d76da0e35bfdfe345798f
> 71b519dd4ce6fe70a9ecaa1e068bc56ea7c0cd4e M include
> :040000 040000 d4f45b70708f5d238eacececb9459c7a88d8ec77
> f70bedd7247a37e14972448f5f1803edc1440fc4 M net
>
> Reverting this commit fixes this issue.
Does the attached patch help? It fixes an old readdir decoding bug that
the above commit happened to expose.
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
[-- Attachment #2: Attached message - [PATCH] NFS: Fix a decoding problem in nfs3_decode_dirent --]
[-- Type: message/rfc822, Size: 3288 bytes --]
From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: stable@kernel.org
Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: [PATCH] NFS: Fix a decoding problem in nfs3_decode_dirent
Date: Thu, 17 Mar 2011 21:54:39 -0400
Message-ID: <1300413279-12570-1-git-send-email-Trond.Myklebust@netapp.com>
When we decode a filename followed by an 8-byte cookie, we need to
consider the fact that the filename and cookie are 32-bit word aligned.
Presently, we may end up copying insufficient amounts of data when
xdr_inline_decode() needs to invoke xdr_copy_to_scratch to deal
with a page boundary.
The following patch fixes the issue by first decoding the filename, and
then decoding the cookie.
Reported-by: Neil Brown <neilb@suse.de>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Reviewed-by: NeilBrown <neilb@suse.de>
---
Hi Greg,
This needs to be applied to 2.6.37 only. The bug in question was
inadvertently fixed by a series of cleanups in 2.6.38, but the patches
in question are too large to be backported. This patch is a minimal fix
that serves the same purpose.
fs/nfs/nfs2xdr.c | 6 ++++--
fs/nfs/nfs3xdr.c | 6 ++++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/fs/nfs/nfs2xdr.c b/fs/nfs/nfs2xdr.c
index b382a1b..33a038d 100644
--- a/fs/nfs/nfs2xdr.c
+++ b/fs/nfs/nfs2xdr.c
@@ -477,11 +477,13 @@ nfs_decode_dirent(struct xdr_stream *xdr, struct nfs_entry *entry, struct nfs_se
entry->ino = ntohl(*p++);
entry->len = ntohl(*p++);
- p = xdr_inline_decode(xdr, entry->len + 4);
+ p = xdr_inline_decode(xdr, entry->len);
if (unlikely(!p))
goto out_overflow;
entry->name = (const char *) p;
- p += XDR_QUADLEN(entry->len);
+ p = xdr_inline_decode(xdr, 4);
+ if (unlikely(!p))
+ goto out_overflow;
entry->prev_cookie = entry->cookie;
entry->cookie = ntohl(*p++);
diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
index ba91236..dcd934f 100644
--- a/fs/nfs/nfs3xdr.c
+++ b/fs/nfs/nfs3xdr.c
@@ -614,11 +614,13 @@ nfs3_decode_dirent(struct xdr_stream *xdr, struct nfs_entry *entry, struct nfs_s
p = xdr_decode_hyper(p, &entry->ino);
entry->len = ntohl(*p++);
- p = xdr_inline_decode(xdr, entry->len + 8);
+ p = xdr_inline_decode(xdr, entry->len);
if (unlikely(!p))
goto out_overflow;
entry->name = (const char *) p;
- p += XDR_QUADLEN(entry->len);
+ p = xdr_inline_decode(xdr, 8);
+ if (unlikely(!p))
+ goto out_overflow;
entry->prev_cookie = entry->cookie;
p = xdr_decode_hyper(p, &entry->cookie);
--
1.7.4
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [NFS BUG] Resoruces leak caused by commit - NFS: Don't use vm_map_ram() in readdir (55ea499d60aefa3d03a77fc8590c26b5881faa92)
2011-03-21 17:05 ` Trond Myklebust
@ 2011-03-21 19:47 ` Jacek Luczak
0 siblings, 0 replies; 3+ messages in thread
From: Jacek Luczak @ 2011-03-21 19:47 UTC (permalink / raw)
To: Trond Myklebust; +Cc: mkl, gregkh, LKML
Hi Trond,
yep, this one fixes the issue (applied to 2.6.37.4).
Tested-by: Jacek Luczak <jacek.luczak.ext@nsn.com>
Thanks,
-Jacek
2011/3/21 Trond Myklebust <Trond.Myklebust@netapp.com>:
> On Mon, 2011-03-21 at 17:53 +0100, Jacek Luczak wrote:
>> Hi,
>>
>> *BRIEF*: Reading lot of files from nfs mounted on directory lead to a
>> resources leak. Affected Kernels: 2.6.37.1-2.6.37.4, did not tested on
>> 2.6.38 (assume that issue is also there).
>>
>> Steps to reproduce:
>> 1) cd /some/nfs/mounted/dir
>> 2) find . -type f | wc -l
>> On healthy system this will give a number of files below the dir - in
>> my test env. this gives 692 files. On broken system after a while when
>> whole memory will be consumed this will throw:
>> find: memory exhausted
>>
>> Reproduced same with rsync to local storage:
>> sending incremental file list
>> [sender] expand file_list pointer array to 524288 bytes, did move
>> [sender] expand file_list pointer array to 1048576 bytes, did move
>> [sender] expand file_list pointer array to 2097152 bytes, did move
>> [sender] expand file_list pointer array to 4194304 bytes, did move
>> [sender] expand file_list pointer array to 8388608 bytes, did move
>> [sender] expand file_list pointer array to 16777216 bytes, did move
>> [sender] expand file_list pointer array to 33554432 bytes, did move
>> [sender] expand file_list pointer array to 67108864 bytes, did move
>> [sender] expand file_list pointer array to 134217728 bytes, did move
>> [sender] expand file_list pointer array to 268435456 bytes, did move
>> [sender] expand file_list pointer array to 402653184 bytes, did move
>> [sender] expand file_list pointer array to 536870912 bytes, did move
>> [sender] expand file_list pointer array to 671088640 bytes, did move
>> [sender] expand file_list pointer array to 805306368 bytes, did move
>> [sender] expand file_list pointer array to 939524096 bytes, did move
>> [sender] expand file_list pointer array to 1073741824 bytes, did move
>> Same results as with find - memory consumption bumps to all available space.
>>
>> Bisected this down to commit:
>> 55ea499d60aefa3d03a77fc8590c26b5881faa92 is the first bad commit
>> commit 55ea499d60aefa3d03a77fc8590c26b5881faa92
>> Author: Trond Myklebust <Trond.Myklebust@netapp.com>
>> Date: Sat Jan 8 17:45:38 2011 -0500
>>
>> NFS: Don't use vm_map_ram() in readdir
>>
>> commit 6650239a4b01077e80d5a4468562756d77afaa59 upstream.
>>
>> vm_map_ram() is not available on NOMMU platforms, and causes trouble
>> on incoherrent architectures such as ARM when we access the page data
>> through both the direct and the virtual mapping.
>>
>> The alternative is to use the direct mapping to access page data
>> for the case when we are not crossing a page boundary, but to copy
>> the data into a linear scratch buffer when we are accessing data
>> that spans page boundaries.
>>
>> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
>> Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>>
>> :040000 040000 b8416029d026cd8e43d6517bcce32ea86180d31a
>> 49dd8041519101ab68075b502ad18127f6ab86d4 M fs
>> :040000 040000 9332a8f43f88b80dd11d76da0e35bfdfe345798f
>> 71b519dd4ce6fe70a9ecaa1e068bc56ea7c0cd4e M include
>> :040000 040000 d4f45b70708f5d238eacececb9459c7a88d8ec77
>> f70bedd7247a37e14972448f5f1803edc1440fc4 M net
>>
>> Reverting this commit fixes this issue.
>
> Does the attached patch help? It fixes an old readdir decoding bug that
> the above commit happened to expose.
>
> Trond
> --
> Trond Myklebust
> Linux NFS client maintainer
>
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com
>
>
>
> ---------- Wiadomość przekazana dalej ----------
> From: Trond Myklebust <Trond.Myklebust@netapp.com>
> To: stable@kernel.org
> Date: Thu, 17 Mar 2011 21:54:39 -0400
> Subject: [PATCH] NFS: Fix a decoding problem in nfs3_decode_dirent
> When we decode a filename followed by an 8-byte cookie, we need to
> consider the fact that the filename and cookie are 32-bit word aligned.
> Presently, we may end up copying insufficient amounts of data when
> xdr_inline_decode() needs to invoke xdr_copy_to_scratch to deal
> with a page boundary.
>
> The following patch fixes the issue by first decoding the filename, and
> then decoding the cookie.
>
> Reported-by: Neil Brown <neilb@suse.de>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
> Reviewed-by: NeilBrown <neilb@suse.de>
> ---
> Hi Greg,
>
> This needs to be applied to 2.6.37 only. The bug in question was
> inadvertently fixed by a series of cleanups in 2.6.38, but the patches
> in question are too large to be backported. This patch is a minimal fix
> that serves the same purpose.
>
>
> fs/nfs/nfs2xdr.c | 6 ++++--
> fs/nfs/nfs3xdr.c | 6 ++++--
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/fs/nfs/nfs2xdr.c b/fs/nfs/nfs2xdr.c
> index b382a1b..33a038d 100644
> --- a/fs/nfs/nfs2xdr.c
> +++ b/fs/nfs/nfs2xdr.c
> @@ -477,11 +477,13 @@ nfs_decode_dirent(struct xdr_stream *xdr, struct nfs_entry *entry, struct nfs_se
> entry->ino = ntohl(*p++);
> entry->len = ntohl(*p++);
>
> - p = xdr_inline_decode(xdr, entry->len + 4);
> + p = xdr_inline_decode(xdr, entry->len);
> if (unlikely(!p))
> goto out_overflow;
> entry->name = (const char *) p;
> - p += XDR_QUADLEN(entry->len);
> + p = xdr_inline_decode(xdr, 4);
> + if (unlikely(!p))
> + goto out_overflow;
> entry->prev_cookie = entry->cookie;
> entry->cookie = ntohl(*p++);
>
> diff --git a/fs/nfs/nfs3xdr.c b/fs/nfs/nfs3xdr.c
> index ba91236..dcd934f 100644
> --- a/fs/nfs/nfs3xdr.c
> +++ b/fs/nfs/nfs3xdr.c
> @@ -614,11 +614,13 @@ nfs3_decode_dirent(struct xdr_stream *xdr, struct nfs_entry *entry, struct nfs_s
> p = xdr_decode_hyper(p, &entry->ino);
> entry->len = ntohl(*p++);
>
> - p = xdr_inline_decode(xdr, entry->len + 8);
> + p = xdr_inline_decode(xdr, entry->len);
> if (unlikely(!p))
> goto out_overflow;
> entry->name = (const char *) p;
> - p += XDR_QUADLEN(entry->len);
> + p = xdr_inline_decode(xdr, 8);
> + if (unlikely(!p))
> + goto out_overflow;
> entry->prev_cookie = entry->cookie;
> p = xdr_decode_hyper(p, &entry->cookie);
>
> --
> 1.7.4
>
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-03-21 19:47 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-03-21 16:53 [NFS BUG] Resoruces leak caused by commit - NFS: Don't use vm_map_ram() in readdir (55ea499d60aefa3d03a77fc8590c26b5881faa92) Jacek Luczak
2011-03-21 17:05 ` Trond Myklebust
2011-03-21 19:47 ` Jacek Luczak
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).