[lkml]   [2008]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/3] orphaned pgrp fixes
    Oleg Nesterov <> writes:

    > On 03/04, Roland McGrath wrote:

    >> Since it's after our own
    >> group_dead hit, the "ignored_task" check for our own group leader is
    >> redundant with that.
    > Ah, good point. I didn't realize this when I was thinking about using
    > signal->live.
    > So perhaps it's:
    >> do_each_pid_task(pgrp, PIDTYPE_PGID, p) {
    >> if (task_session(p->real_parent) == task_session(p) &&
    >> task_pgrp(p->real_parent) != pgrp &&
    >> atomic_read(&p->signal->live) > 0 &&
    >> task_tgid_nr_ns(p->real_parent, p->nsproxy->pid_ns) != 1)
    >> return 0;
    >> } while_each_pid_task(pgrp, PIDTYPE_PGID, p);
    > I am hopeless, I can't understand orphaned pgrps.

    I will give it a quick try.
    When you login in text mode you get a fresh session (setsid).
    If you are using job control in your shell each job is assigned
    a separate process group (setpgrp).

    The shell and all process groups are in the same session.

    Intuitively a process group is considered orphaned when there is
    are no processes in the session that know about it and can wake it
    up. The goal is to prevent processes that will never wake up if
    they are stopped with ^Z.

    A process is defined as knowing about a process in a process group
    when it is a parent of that process.

    The task_tgid_nr_ns(p->real_parent, p->nsproxy->pid_ns) == 1 check is
    the proper check, as it handles namespaces properly. If we need to
    retain it.

    I don't believe we need to retain the check for init at all. sysvinit
    doesn't use that feature and I would be surprised if any other init
    did. Except for covering programming bugs which make testing harder
    I don't see how a version of init could care.

    Further as init=/bin/bash is a common idiom for getting into a
    simplified system and debugging it, there is a case for job control
    to work properly for init. Unless I am misreading things the check
    for init prevent us from using job control from our first process.
    Which seems like it would make init=/bin/bash painful if job control
    was ever enabled.

    I believe that the only reason with a weird check for init like we are
    performing that we are POSIX compliant is that our init process can
    count as a special system process and can escape the definition.

    Therefore I think the code would be more maintainable, and the system
    would be less surprising, and more useful if we removed this special
    case processing of init altogether.

    I'm hoping that we can kill this check before pid namespaces are
    widely deployed and a much larger number of programs can run as init.


     \ /
      Last update: 2008-03-06 02:25    [W:0.024 / U:41.480 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site