• Eric W. Biederman's avatar
    fork: Have new threads join on-going signal group stops · 924de3b8
    Eric W. Biederman authored
    There are only two signals that are delivered to every member of a
    signal group: SIGSTOP and SIGKILL.  Signal delivery requires every
    signal appear to be delivered either before or after a clone syscall.
    SIGKILL terminates the clone so does not need to be considered.  Which
    leaves only SIGSTOP that needs to be considered when creating new
    threads.
    
    Today in the event of a group stop TIF_SIGPENDING will get set and the
    fork will restart ensuring the fork syscall participates in the group
    stop.
    
    A fork (especially of a process with a lot of memory) is one of the
    most expensive system so we really only want to restart a fork when
    necessary.
    
    It is easy so check to see if a SIGSTOP is ongoing and have the new
    thread join it immediate after the clone completes.  Making it appear
    the clone completed happened just before the SIGSTOP.
    
    The calculate_sigpending function will see the bits set in jobctl and
    set TIF_SIGPENDING to ensure the new task takes the slow path to userspace.
    
    V2: The call to task_join_group_stop was moved before the new task is
        added to the thread group list.  This should not matter as
        sighand->siglock is held over both the addition of the threads,
        the call to task_join_group_stop and do_signal_stop.  But the change
        is trivial and it is one less thing to worry about when reading
        the code.
    Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
    924de3b8
signal.c 102 KB