Skip to content
  • Eric W. Biederman's avatar
    [PATCH] pidhash: Refactor the pid hash table · 92476d7f
    Eric W. Biederman authored
    
    
    Simplifies the code, reduces the need for 4 pid hash tables, and makes the
    code more capable.
    
    In the discussions I had with Oleg it was felt that to a large extent the
    cleanup itself justified the work.  With struct pid being dynamically
    allocated meant we could create the hash table entry when the pid was
    allocated and free the hash table entry when the pid was freed.  Instead of
    playing with the hash lists when ever a process would attach or detach to a
    process.
    
    For myself the fact that it gave what my previous task_ref patch gave for free
    with simpler code was a big win.  The problem is that if you hold a reference
    to struct task_struct you lock in 10K of low memory.  If you do that in a user
    controllable way like /proc does, with an unprivileged but hostile user space
    application with typical resource limits of 1000 fds and 100 processes I can
    trigger the OOM killer by consuming all of low memory with task structs, on a
    machine wight 1GB of low memory.
    
    If I instead hold a reference to struct pid which holds a pointer to my
    task_struct, I don't suffer from that problem because struct pid is 2 orders
    of magnitude smaller.  In fact struct pid is small enough that most other
    kernel data structures dwarf it, so simply limiting the number of referring
    data structures is enough to prevent exhaustion of low memory.
    
    This splits the current struct pid into two structures, struct pid and struct
    pid_link, and reduces our number of hash tables from PIDTYPE_MAX to just one.
    struct pid_link is the per process linkage into the hash tables and lives in
    struct task_struct.  struct pid is given an indepedent lifetime, and holds
    pointers to each of the pid types.
    
    The independent life of struct pid simplifies attach_pid, and detach_pid,
    because we are always manipulating the list of pids and not the hash table.
    In addition in giving struct pid an indpendent life it makes the concept much
    more powerful.
    
    Kernel data structures can now embed a struct pid * instead of a pid_t and
    not suffer from pid wrap around problems or from keeping unnecessarily
    large amounts of memory allocated.
    
    Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    92476d7f