On 05/04/2015 05:26 AM, Paolo Bonzini wrote: > > > On 02/05/2015 07:27, Ingo Molnar wrote: >> >> - synchronize_rcu() avoids having to send an IPI by taking a >> peak at rq->curr's pt_regs::flag, and if: >> >> - the flag is 0 then it has observed a quiescent state. >> >> - the flag is 1, then it would set TIF_NOHZ and wait for a >> completion from a TIF_NOHZ callback. > > Isn't this racy? > > synchronize_rcu CPU nohz CPU > --------------------------------------------------------- > set flag = 0 > read flag = 0 > return to userspace > set TIF_NOHZ > > and there's no guarantee that TIF_NOHZ is ever processed by the nohz CPU.
Actually, the "race" in this direction is fine. If flag==0, then the nohz CPU is not accessing any RCU protected data structures, and the synhcronize_rcu CPU will not be setting TIF_NOHZ. The race is only a concern if the synchronize_rcu CPU reads flag==1 (nohz CPU is in kernel space), and sets TIF_NOHZ after the nohz CPU has cleared flag (and is unable to handle RCU stuff). An atomic compare and swap prevents that issue. The other race, of the synchronize_rcu CPU reading 0, followed by the nohz CPU going into kernel space, and setting the flag to 1, should be fine. After all, this means the nohz_full CPU just went into a new RCU grace period, which is just what the synchronize_rcu CPU was waiting for. -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
