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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
