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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
