struct file leakage

PATCH In review Kirill Korotaev 5 participants 7 messages Jul 10, 2006 – Jul 12, 2006 VFS

lore

Share & tools

lore

Kirill Korotaev

author

2006-07-10 09:05 UTC #0 lore raw

PATCH 1/1 struct file leakage

Hello!

Andrew, this is a patch from Alexey Kuznetsov for 2.6.16. I believe 2.6.17 still has this leak.

-------------------------------------------------------------

2.6.16 leaks like hell. While testing, I found massive leakage (reproduced in openvz) in:

*filp
*size-4096

And 1 object leaks in
*size-32
*size-64
*size-128

It is the fix for the first one. filp leaks in the bowels of namei.c.

Seems, size-4096 is file table leaking in expand_fdtables.

I have no idea what are the rest and why they show only accompaniing another leaks. Some debugging structs?

Signed-off-by Alexey Kuznetsov <[email protected]>

CC Kirill Korotaev <[email protected]>

fs/namei.c +8 -1

@@ -1774,8 +1774,15 @@ do_link:
 	if (error)
 		goto exit_dput;
 	error = __do_follow_link(&path, nd);
-	if (error)
+	if (error) {
+		/* Does someone understand code flow here? Or it is only
+		 * me so stupid? Anathema to whoever designed this non-sense
+		 * with "intent.open".
+		 */
+		if (!IS_ERR(nd->intent.open.file))
+			release_open_intent(nd);
 		return error;
+	}
 	nd->flags &= ~LOOKUP_PARENT;
 	if (nd->last_type == LAST_BIND)
 		goto ok;

Andrew Morton

2006-07-10 10:06 UTC #1 lore raw

Quoted 19 lines · On Mon, 10 Jul 2006 13:05:35 +0400 Kirill Korotaev <[email protected]> wrote:

Hello!
Andrew, this is a patch from Alexey Kuznetsov for 2.6.16. I believe 2.6.17 still has this leak.
-------------------------------------------------------------
2.6.16 leaks like hell. While testing, I found massive leakage (reproduced in openvz) in:
*filp
*size-4096
And 1 object leaks in
*size-32
*size-64
*size-128

Quoted 4 lines

It is the fix for the first one. filp leaks in the bowels of namei.c.
Seems, size-4096 is file table leaking in expand_fdtables.

I suspect that's been there for a long time.

Quoted 2 lines

I have no idea what are the rest and why they show only accompaniing another leaks. Some debugging structs?

I don't understand this. Are you implying that there are other bugs.

Quoted 14 lines

Signed-off-by Alexey Kuznetsov <[email protected]>

CC Kirill Korotaev <[email protected]>

fs/namei.c +2 -1

@@ -1774,8 +1774,15 @@ do_link:
 	if (error)
 		goto exit_dput;
 	error = __do_follow_link(&path, nd);
-	if (error)
+	if (error) {
+		/* Does someone understand code flow here? Or it is only

fs/namei.c do_link: · line 1788

Quoted 10 lines

fs/namei.c +6 -0

+		 * me so stupid? Anathema to whoever designed this non-sense
+		 * with "intent.open".
+		 */
+		if (!IS_ERR(nd->intent.open.file))
+			release_open_intent(nd);
 		return error;
+	}
 	nd->flags &= ~LOOKUP_PARENT;
 	if (nd->last_type == LAST_BIND)
 		goto ok;

It's good to have some more Alexeycomments in the tree.

I wonder if we're also needing a path_release() here. And if not, whether it is still safe to run release_open_intent() against this nameidata?

Hopefully Trond can recall what's going on in there...

Alexey Kuznetsov

2006-07-10 10:17 UTC #2 lore raw

Hello!

Quoted 1 line

I don't understand this. Are you implying that there are other bugs.

Yes. I still see leakage of another objects, most likely fdtables. Probably, it is an internal bleeding of openvz or it was already fixed in mainstreem. I still do not know.

Alexey

Trond Myklebust

2006-07-11 12:04 UTC #3 lore raw

In reply to Andrew Morton

Quoted 61 lines · Andrew Morton

Quoted 19 lines · On Mon, 10 Jul 2006 13:05:35 +0400 Kirill Korotaev <[email protected]> wrote:
Hello!
Andrew, this is a patch from Alexey Kuznetsov for 2.6.16. I believe 2.6.17 still has this leak.
-------------------------------------------------------------
2.6.16 leaks like hell. While testing, I found massive leakage (reproduced in openvz) in:
*filp
*size-4096
And 1 object leaks in
*size-32
*size-64
*size-128
Quoted 4 lines
It is the fix for the first one. filp leaks in the bowels of namei.c.
Seems, size-4096 is file table leaking in expand_fdtables.
I suspect that's been there for a long time.
Quoted 2 lines
I have no idea what are the rest and why they show only accompaniing another leaks. Some debugging structs?
I don't understand this. Are you implying that there are other bugs.
Quoted 14 lines
Signed-off-by Alexey Kuznetsov <[email protected]>
CC Kirill Korotaev <[email protected]>
fs/namei.c +2 -1
@@ -1774,8 +1774,15 @@ do_link:
 	if (error)
 		goto exit_dput;
 	error = __do_follow_link(&path, nd);
-	if (error)
+	if (error) {
+		/* Does someone understand code flow here? Or it is only
fs/namei.c do_link: · line 1788
Quoted 10 lines
fs/namei.c +6 -0
+		 * me so stupid? Anathema to whoever designed this non-sense
+		 * with "intent.open".
+		 */
+		if (!IS_ERR(nd->intent.open.file))
+			release_open_intent(nd);
 		return error;
+	}
 	nd->flags &= ~LOOKUP_PARENT;
 	if (nd->last_type == LAST_BIND)
 		goto ok;
It's good to have some more Alexeycomments in the tree.

Quoted 4 lines

I wonder if we're also needing a path_release() here. And if not, whether it is still safe to run release_open_intent() against this nameidata?
Hopefully Trond can recall what's going on in there...

The patch looks correct, except that I believe we can skip the IS_ERR() test there: if we're following links then we presumably have not tried to open any files yet, so the call to release_open_intent(nd) can be made unconditional.

Cheers,
Trond

Andrew Morton

2006-07-11 23:30 UTC #4 lore raw

Quoted 21 lines · Trond Myklebust

Quoted 21 lines
Quoted 5 lines
fs/namei.c +2 -1
-	if (error)
+	if (error) {
+		/* Does someone understand code flow here? Or it is only
fs/namei.c do_link: · line 1788
Quoted 10 lines
fs/namei.c +6 -0
+		 * me so stupid? Anathema to whoever designed this non-sense
+		 * with "intent.open".
+		 */
+		if (!IS_ERR(nd->intent.open.file))
+			release_open_intent(nd);
 		return error;
+	}
 	nd->flags &= ~LOOKUP_PARENT;
 	if (nd->last_type == LAST_BIND)
 		goto ok;
It's good to have some more Alexeycomments in the tree.
I wonder if we're also needing a path_release() here. And if not, whether it is still safe to run release_open_intent() against this nameidata?

Quoted 6 lines

Quoted 1 line
Hopefully Trond can recall what's going on in there...
The patch looks correct, except that I believe we can skip the IS_ERR() test there: if we're following links then we presumably have not tried to open any files yet, so the call to release_open_intent(nd) can be made unconditional.

Sorry, but phrases like "looks correct" and "I believe" don't inspire confidence. (Although what you say looks correct ;)) Are you sure?

And do we also need a path_release(nd) in there?

Trond Myklebust

2006-07-12 00:26 UTC #5 lore raw

Quoted 24 lines · Andrew Morton

Quoted 23 lines · Trond Myklebust
Quoted 22 lines
Quoted 5 lines
fs/namei.c +2 -1
-	if (error)
+	if (error) {
+		/* Does someone understand code flow here? Or it is only
fs/namei.c do_link: · line 1788
Quoted 10 lines
fs/namei.c +6 -0
+		 * me so stupid? Anathema to whoever designed this non-sense
+		 * with "intent.open".
+		 */
+		if (!IS_ERR(nd->intent.open.file))
+			release_open_intent(nd);
 		return error;
+	}
 	nd->flags &= ~LOOKUP_PARENT;
 	if (nd->last_type == LAST_BIND)
 		goto ok;
It's good to have some more Alexeycomments in the tree.
I wonder if we're also needing a path_release() here. And if not, whether it is still safe to run release_open_intent() against this nameidata?
Hopefully Trond can recall what's going on in there...

Quoted 7 lines

Quoted 4 lines
The patch looks correct, except that I believe we can skip the IS_ERR() test there: if we're following links then we presumably have not tried to open any files yet, so the call to release_open_intent(nd) can be made unconditional.
Sorry, but phrases like "looks correct" and "I believe" don't inspire confidence. (Although what you say looks correct ;)) Are you sure?

We do need the call to release_open_intent(), since otherwise we will leak a struct file. The question is whether we can optimise away the IS_ERR() test. In my opinion, we can.

Quoted 1 line

And do we also need a path_release(nd) in there?

No. do_follow_link() should release the path for us on error. Replacing with a 'goto exit' would therefore be a mistake.

Cheers,
Trond

Eric W. Biederman

2006-07-10 11:57 UTC #6 lore raw

In reply to Kirill Korotaev

Quoted 19 lines · Kirill Korotaev

Hello!
Andrew, this is a patch from Alexey Kuznetsov for 2.6.16. I believe 2.6.17 still has this leak.
-------------------------------------------------------------
2.6.16 leaks like hell. While testing, I found massive leakage (reproduced in openvz) in:
*filp
*size-4096
And 1 object leaks in
*size-32
*size-64
*size-128

Quoted 7 lines

It is the fix for the first one. filp leaks in the bowels of namei.c.
Seems, size-4096 is file table leaking in expand_fdtables.
I have no idea what are the rest and why they show only accompaniing another leaks. Some debugging structs?

Or something the intent or the filp holds a reference to?

Looks like this has been broken since 834f2a4a1554dc5b2598038b3fe8703defcbe467 about 9 months ago.

The patch looks sane.

Trond did you just miss this case?

Quoted 12 lines

Signed-off-by Alexey Kuznetsov <[email protected]>

CC Kirill Korotaev <[email protected]>

fs/namei.c +2 -1

@@ -1774,8 +1774,15 @@ do_link:
 	if (error)
 		goto exit_dput;
 	error = __do_follow_link(&path, nd);
-	if (error)
+	if (error) {
+		/* Does someone understand code flow here? Or it is only

fs/namei.c do_link: · line 1788

Quoted 10 lines

fs/namei.c +6 -0

+		 * me so stupid? Anathema to whoever designed this non-sense
+		 * with "intent.open".
+		 */
+		if (!IS_ERR(nd->intent.open.file))
+			release_open_intent(nd);
 		return error;
+	}
 	nd->flags &= ~LOOKUP_PARENT;
 	if (nd->last_type == LAST_BIND)
 		goto ok;

Eric