Re: 2.6.13.3 Memory leak, names_cache

From: Rick Lindsley (ricklind_at_us.ibm.com)
Date: 10/06/05

  • Next message: Stefan Smietanowski: "Re: freebox possible GPL violation"
    To: Robert Derr <rderr@weatherflow.com>
    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-2.6.13.3/fs/namei.c 2005-08-28 16:41:01.000000000 -0700
    +++ linux-2.6.13.3-new/fs/namei.c 2005-10-06 12:45:41.996243768 -0700
    @@ -1557,19 +1557,19 @@ do_link:
             if (nd->last_type != LAST_NORM)
                     goto exit;
             if (nd->last.name[nd->last.len]) {
    - putname(nd->last.name);
    + __putname(nd->last.name);
                     goto exit;
             }
             error = -ELOOP;
             if (count++==32) {
    - putname(nd->last.name);
    + __putname(nd->last.name);
                     goto exit;
             }
             dir = nd->dentry;
             down(&dir->d_inode->i_sem);
             path.dentry = __lookup_hash(&nd->last, nd->dentry, nd);
             path.mnt = nd->mnt;
    - putname(nd->last.name);
    + __putname(nd->last.name);
             goto do_last;
     }
     
    -
    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/


  • 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 ...
      (Linux-Kernel)
    • 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 ...
      (Linux-Kernel)
    • 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 http://vger.kernel.org/majordomo-info.html ...
      (Linux-Kernel)
    • 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 ...
      (Linux-Kernel)
    • Re: [RFC][2.6.12.3] IRQ compression/sharing patch
      ... > that is shared by both architectures and which is included when ... I was thinking of IO-APIC hotplug here. ... Ok I guess they can change it in that patch then. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)