Re: 2.6.13.3 Memory leak, names_cache

[Rick Lindsley]

Are you running with CONFIG_AUDITSYSCALL?

We ran into what sounds like the same problem and we're testing
a patch right now for a names_cache growth which only occurs
with CONFIG_AUDITSYSCALL enabled, and then only every time you
traverse a symlink.  In open_namei(), in the do_link section, we call
__do_follow_link() which will bypass the auditing whether it's enabled
or not.  However at the end of this section, we will call putname(),
which will *not* actually do a __putname() if auditing is enabled because
it believes it will happen at syscall return.  So we slowly lose memory
with each link traversal.

The code in open_namei() is a bit non-intuitive in error conditions,
but the general fix appears to be pretty straightforward.  Let me know if
this patch seems to do the trick for you.


--- linux-2.6.13.3/fs/namei.c	2005-08-28 16:41:01.000000000 -0700
+++ linux-2.6.13.3-new/fs/namei.c	2005-10-06 12:45:41.996243768 -0700
@@ -1557,19 +1557,19 @@ do_link:
 	if (nd->last_type != LAST_NORM)
 		goto exit;
 	if (nd->last.name[nd->last.len]) {
-		putname(nd->last.name);
+		__putname(nd->last.name);
 		goto exit;
 	}
 	error = -ELOOP;
 	if (count++==32) {
-		putname(nd->last.name);
+		__putname(nd->last.name);
 		goto exit;
 	}
 	dir = nd->dentry;
 	down(&dir->d_inode->i_sem);
 	path.dentry = __lookup_hash(&nd->last, nd->dentry, nd);
 	path.mnt = nd->mnt;
-	putname(nd->last.name);
+	__putname(nd->last.name);
 	goto do_last;
 }
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/