Messages in this thread | | | Date | Fri, 30 Jun 2017 10:31:26 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [GIT PULL rcu/next] RCU commits for 4.13 |
| |
On Fri, Jun 30, 2017 at 01:16:54PM +0800, Boqun Feng wrote: > On Thu, Jun 29, 2017 at 09:02:41PM -0700, Paul E. McKenney wrote:
[ . . . ]
> > > > o kernel/task_work.c task_work_run() > > > > Seems to rely on the acquire semantics only. This is to handle > > > > > > I think this one needs the stronger semantics, the smp_mb() is just > > > hidden in the cmpxchg() before the raw_spin_unlock_wait() ;-) > > > > > > cmpxchg() sets a special value to indicate the task_work has been taken, > > > and raw_spin_unlock_wait() must wait until the next critical section of > > > ->pi_lock(in task_work_cancel()) could observe this, otherwise we may > > > cancel a task_work while executing it. > > > > But either way, replacing the spin_unlock_wait() with a spin_lock() > > immediately followed by a spin_unlock() should work correctly, right? > > > > Yep ;-) I was thinking about the case that we kept spin_unlock_wait() > with a simpler acquire semantics, and if so, we would actually have to > do the replace. But I saw your patchset of removing it, so it doesn't > matter.
Well, there is a fair amount of review and testing between now and it getting in (assuming that it in fact does get in), but I do very much appreciate the vote of confidence! ;-)
Thanx, Paul
| |