Messages in this thread | | | Date | Mon, 04 May 2015 10:19:10 -0400 | From | Rik van Riel <> | Subject | Re: [PATCH 3/3] context_tracking,x86: remove extraneous irq disable & enable from context tracking on syscall entry |
| |
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
| |