Skip to content
  • Andrew Vagin's avatar
    pidns: limit the nesting depth of pid namespaces · f2302505
    Andrew Vagin authored
    
    
    'struct pid' is a "variable sized struct" - a header with an array of
    upids at the end.
    
    The size of the array depends on a level (depth) of pid namespaces.  Now a
    level of pidns is not limited, so 'struct pid' can be more than one page.
    
    Looks reasonable, that it should be less than a page.  MAX_PIS_NS_LEVEL is
    not calculated from PAGE_SIZE, because in this case it depends on
    architectures, config options and it will be reduced, if someone adds a
    new fields in struct pid or struct upid.
    
    I suggest to set MAX_PIS_NS_LEVEL = 32, because it saves ability to expand
    "struct pid" and it's more than enough for all known for me use-cases.
    When someone finds a reasonable use case, we can add a config option or a
    sysctl parameter.
    
    In addition it will reduce the effect of another problem, when we have
    many nested namespaces and the oldest one starts dying.
    zap_pid_ns_processe will be called for each namespace and find_vpid will
    be called for each process in a namespace.  find_vpid will be called
    minimum max_level^2 / 2 times.  The reason of that is that when we found a
    bit in pidmap, we can't determine this pidns is top for this process or it
    isn't.
    
    vpid is a heavy operation, so a fork bomb, which create many nested
    namespace, can make a system inaccessible for a long time.  For example my
    system becomes inaccessible for a few minutes with 4000 processes.
    
    [akpm@linux-foundation.org: return -EINVAL in response to excessive nesting, not -ENOMEM]
    Signed-off-by: default avatarAndrew Vagin <avagin@openvz.org>
    Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
    Cc: Cyrill Gorcunov <gorcunov@openvz.org>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Pavel Emelyanov <xemul@parallels.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    f2302505