lkml.org 
[lkml]   [2005]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.13.3 Memory leak, names_cache
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-10-06 23:20    [W:0.066 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site