lkml.org 
[lkml]   [2017]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 4.13 006/109] srcu: Provide ordering for CPU not involved in grace period
    Date
    4.13-stable review patch.  If anyone has any objections, please let me know.

    ------------------

    From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

    commit 35732cf9dd38b1efb0f2f22c91c61b51337d1ac3 upstream.

    Tree RCU guarantees that every online CPU has a memory barrier between
    any given grace period and any of that CPU's RCU read-side sections that
    must be ordered against that grace period. Since RCU doesn't always
    know where read-side critical sections are, the actual implementation
    guarantees order against prior and subsequent non-idle non-offline code,
    whether in an RCU read-side critical section or not. As a result, there
    does not need to be a memory barrier at the end of synchronize_rcu()
    and friends because the ordering internal to the grace period has
    ordered every CPU's post-grace-period execution against each CPU's
    pre-grace-period execution, again for all non-idle online CPUs.

    In contrast, SRCU can have non-idle online CPUs that are completely
    uninvolved in a given SRCU grace period, for example, a CPU that
    never runs any SRCU read-side critical sections and took no part in
    the grace-period processing. It is in theory possible for a given
    synchronize_srcu()'s wakeup to be delivered to a CPU that was completely
    uninvolved in the prior SRCU grace period, which could mean that the
    code following that synchronize_srcu() would end up being unordered with
    respect to both the grace period and any pre-existing SRCU read-side
    critical sections.

    This commit therefore adds an smp_mb() to the end of __synchronize_srcu(),
    which prevents this scenario from occurring.

    Reported-by: Lance Roy <ldr709@gmail.com>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Acked-by: Lance Roy <ldr709@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    ---
    kernel/rcu/srcutree.c | 9 +++++++++
    1 file changed, 9 insertions(+)

    --- a/kernel/rcu/srcutree.c
    +++ b/kernel/rcu/srcutree.c
    @@ -896,6 +896,15 @@ static void __synchronize_srcu(struct sr
    __call_srcu(sp, &rcu.head, wakeme_after_rcu, do_norm);
    wait_for_completion(&rcu.completion);
    destroy_rcu_head_on_stack(&rcu.head);
    +
    + /*
    + * Make sure that later code is ordered after the SRCU grace
    + * period. This pairs with the raw_spin_lock_irq_rcu_node()
    + * in srcu_invoke_callbacks(). Unlike Tree RCU, this is needed
    + * because the current CPU might have been totally uninvolved with
    + * (and thus unordered against) that grace period.
    + */
    + smp_mb();
    }

    /**

    \
     
     \ /
      Last update: 2017-09-24 23:01    [W:6.082 / U:1.188 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site