Rick Lindsley wrote:
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.
Thanks Rick and Linus,
Rick, I put in your patch and after running for 15 minutes the system is
holding steady at around 60-80 allocations. Before it would have
already have been up to a few thousand. I'll know for sure tomorrow
morning.
Thanks again for everyone's help,
Robert J Derr
Weatherflow, Inc.
-
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]
