Message-ID: <43459458.9080808@weatherflow.com>
Date: Thu, 06 Oct 2005 17:17:12 -0400
From: Robert Derr <rderr@weatherflow.com>
User-Agent: Thunderbird 1.4 (Windows/20050908)
MIME-Version: 1.0
To: Rick Lindsley <ricklind@us.ibm.com>
CC: linux-kernel@vger.kernel.org, amitarora@in.ibm.com, suzukikp@in.ibm.com,
       torvalds@osdl.org
Subject: Re: 2.6.13.3 Memory leak, names_cache
References: <200510062003.j96K3In0016900@owlet.beaverton.ibm.com>
In-Reply-To: <200510062003.j96K3In0016900@owlet.beaverton.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1414
Lines: 36

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/