• Eric W. Biederman's avatar
    tasks, sched/core: Ensure tasks are available for a grace period after leaving the runqueue · 0ff7b2cf
    Eric W. Biederman authored
    In the ordinary case today the RCU grace period for a task_struct is
    triggered when another process wait's for it's zombine and causes the
    kernel to call release_task().  As the waiting task has to receive a
    signal and then act upon it before this happens, typically this will
    occur after the original task as been removed from the runqueue.
    
    Unfortunaty in some cases such as self reaping tasks it can be shown
    that release_task() will be called starting the grace period for
    task_struct long before the task leaves the runqueue.
    
    Therefore use put_task_struct_rcu_user() in finish_task_switch() to
    guarantee that the there is a RCU lifetime after the task
    leaves the runqueue.
    
    Besides the change in the start of the RCU grace period for the
    task_struct this change may cause perf_event_delayed_put and
    trace_sched_process_free.  The function perf_event_delayed_put boils
    down to just a WARN_ON for cases that I assume never show happen.  So
    I don't see any problem with delaying it.
    
    The function trace_sched_process_free is a trace point and thus
    visible to user space.  Occassionally userspace has the strangest
    dependencies so this has a miniscule chance of causing a regression.
    This change only changes the timing of when the tracepoint is called.
    The change in timing arguably gives userspace a more accurate picture
    of what is going on.  So I don't expect there to be a regression.
    
    In the case where a task self reaps we are pretty much guaranteed that
    the RCU grace period is delayed.  So we should get quite a bit of
    coverage in of this worst case for the change in a normal threaded
    workload.  So I expect any issues to turn up quickly or not at all.
    
    I have lightly tested this change and everything appears to work
    fine.
    Inspired-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    Inspired-by: default avatarOleg Nesterov <oleg@redhat.com>
    Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Chris Metcalf <cmetcalf@ezchip.com>
    Cc: Christoph Lameter <cl@linux.com>
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Kirill Tkhai <tkhai@yandex.ru>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Paul E. McKenney <paulmck@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lkml.kernel.org/r/87r24jdpl5.fsf_-_@x220.int.ebiederm.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
    0ff7b2cf
fork.c 70.1 KB