Re: Memory leak, names_cache

From: Rick Lindsley (
Date: 10/06/05

  • Next message: Stefan Smietanowski: "Re: freebox possible GPL violation"
    To: Robert Derr <>
    Date:	Thu, 06 Oct 2005 13:03:18 -0700

    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- 2005-08-28 16:41:01.000000000 -0700
    +++ linux- 2005-10-06 12:45:41.996243768 -0700
    @@ -1557,19 +1557,19 @@ do_link:
             if (nd->last_type != LAST_NORM)
                     goto exit;
             if (nd->[nd->last.len]) {
    - putname(nd->;
    + __putname(nd->;
                     goto exit;
             error = -ELOOP;
             if (count++==32) {
    - putname(nd->;
    + __putname(nd->;
                     goto exit;
             dir = nd->dentry;
             path.dentry = __lookup_hash(&nd->last, nd->dentry, nd);
             path.mnt = nd->mnt;
    - putname(nd->;
    + __putname(nd->;
             goto do_last;
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

  • Next message: Stefan Smietanowski: "Re: freebox possible GPL violation"

    Relevant Pages

    • Re: [parisc-linux] Re: [PATCH 3/9] mm: parisc pte atomicity
      ... using your own tmpalias area sounds much better than getting ... I've simply not wrapped my head around the races, ... it looks like we agree that my patch is necessary and valid as is; ... send the line "unsubscribe linux-kernel" in ...
    • Re: keyboard - was: Re: Linux 2.6.0-test4
      ... >> I was able to get the key unstuck by switching back and forth between ... I rebuild my kernel including your patch; ... I'll get back to you once I verify that the problem doesn't occur ... send the line "unsubscribe linux-kernel" in ...
    • Re: [CFT][PATCH] 2.6.4-rc1 remove x86 boot page tables
      ... > For VISWS I think you actually need to turn paging off explicitly. ... The patch will need a few tweaks but it should be fairly straight forward. ... send the line "unsubscribe linux-kernel" in ...
    • Re: [PATCH] clarify message and give support contact for non-GPL modules
      ... The author of the second module ... So here is another attempt at the patch. ... send the line "unsubscribe linux-kernel" in ... More majordomo info at ...
    • Re: [PATCH 4/5] random periodicity detection fix
      ... >> WAY overestimating input entropy. ... > My patch did the opposite of your patch: ... 5/5 is a step in that direction, but the filtering is ... send the line "unsubscribe linux-kernel" in ...