Skip to contentSkip to conversation

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
#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;
#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...

#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

#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

#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

#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?

#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