lkml.org 
[lkml]   [2005]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Fix RCU race in access of nohz_cpu_mask
    Srivatsa Vaddagiri wrote:
    >
    > Accessing nohz_cpu_mask before incrementing rcp->cur is racy. It can
    > cause tickless idle CPUs to be included in rsp->cpumask, which will
    > extend graceperiods unnecessarily.
    > ...
    > @@ -244,15 +244,15 @@ static void rcu_start_batch(struct rcu_c
    >
    > if (rcp->next_pending &&
    > rcp->completed == rcp->cur) {
    > - /* Can't change, since spin lock held. */
    > - cpus_andnot(rsp->cpumask, cpu_online_map, nohz_cpu_mask);
    > -
    > rcp->next_pending = 0;
    > /* next_pending == 0 must be visible in __rcu_process_callbacks()
    > * before it can see new value of cur.
    > */
    > smp_wmb();
    > rcp->cur++;
    > + smp_mb();
    > + cpus_andnot(rsp->cpumask, cpu_online_map, nohz_cpu_mask);
    > +

    Could you explain why this patch makes any difference?

    grep shows the only user of nohz_cpu_mask in arch/s390/kernel/time.c,
    start_hz_timer() and stop_hz_timer().

    I can't see how this change can prevent idle cpus to be included in
    ->cpumask, cpu can add itself to nohz_cpu_mask right after some other
    cpu started new grace period.

    I think cpu should call cpu_quiet() after adding itself to nohz mask
    to eliminate this race.

    No?

    Oleg.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-12-08 19:18    [W:0.020 / U:146.780 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site