[lkml]   [2008]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2/7] proc: Implement support for automounts in task directories
    Andrew Morton <> writes:

    > I was thinking more along the lines of some repeated operation which
    > generates reclaimable storage, only nothing reclaims that storage
    > sufficiently promptly (the 500 second delay, perhaps).
    > Like the problem we had with SLAB_DESTROY_BY_RCU and, umm, I think it
    > was route cache entries increasing like mad and not getting reaped.

    Well what happens is I run reclaim that chain whenever a process
    exits or every 500s. The 500s is really the backup in case
    we don't have any processes exiting, which is a really
    strange workload.

    Now maybe there is an extremely perverse case out there that
    can trigger some bad behavior. But I can't think of anything
    like that at the moment. It would require accessing a lot
    of /proc/<pid>/net directories and holding them open even after
    their files were gone, pinning a lot of mounts, and then
    use a lot of memory elsewhere. Where the problem would
    be that the code is not well tied in with memory reclaim.

    A mount is not a big or expensive structure and it requires
    a fd somewhere to keep it alive past exit. Thinking back
    to my analysis on /proc a few years ago where I introduced
    struct pid to prevent lowmem exhaustion. I can't think of
    a case where it would be a problem or user triggerable.
    Basically you have to have a fd open for every proc inode
    that lives past process exit. And we have hard limits on
    the number of fds a process can open and limits on the
    number of processes we can have.

    One of the things on my todo list to look at sometime is the issue
    that mounts can deny you the permission to delete a file or directory
    when the mount is in another mount namespace. It is a pretty nasty
    DOS from my opinion. Especially when the last process holding open
    the mount namespace oopses and there is no way to remove the mount.
    However that DOS is only available to root today so it doesn't feel
    like a huge danger. To fix that we would need to introduce some
    better mount reaping logic. Which I expect would remove the need for
    the proc_automounts. That is tricky subtle vfs logic and I don't
    plan to rush into it.


     \ /
      Last update: 2008-11-07 18:07    [W:0.024 / U:5.900 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site