Skip to content
  • Eric W. Biederman's avatar
    kthread: don't depend on work queues · 73c27992
    Eric W. Biederman authored
    
    
    Currently there is a circular reference between work queue initialization
    and kthread initialization.  This prevents the kthread infrastructure from
    initializing until after work queues have been initialized.
    
    We want the properties of tasks created with kthread_create to be as close
    as possible to the init_task and to not be contaminated by user processes.
    The later we start our kthreadd that creates these tasks the harder it is
    to avoid contamination from user processes and the more of a mess we have
    to clean up because the defaults have changed on us.
    
    So this patch modifies the kthread support to not use work queues but to
    instead use a simple list of structures, and to have kthreadd start from
    init_task immediately after our kernel thread that execs /sbin/init.
    
    By being a true child of init_task we only have to change those process
    settings that we want to have different from init_task, such as our process
    name, the cpus that are allowed, blocking all signals and setting SIGCHLD
    to SIG_IGN so that all of our children are reaped automatically.
    
    By being a true child of init_task we also naturally get our ppid set to 0
    and do not wind up as a child of PID == 1.  Ensuring that tasks generated
    by kthread_create will not slow down the functioning of the wait family of
    functions.
    
    [akpm@linux-foundation.org: use interruptible sleeps]
    Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
    Cc: Oleg Nesterov <oleg@tv-sign.ru>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    73c27992