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"