Messages in this thread | | | Date | Thu, 08 Dec 2005 22:31:06 +0300 | From | Oleg Nesterov <> | Subject | Re: [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/
| |