Messages in this thread | | | Date | Fri, 6 Mar 2015 19:39:44 +0000 (UTC) | From | Mathieu Desnoyers <> | Subject | Re: Possible lock-less list race in scheduler_ipi() |
| |
----- Original Message ----- > From: "Steven Rostedt" <rostedt@goodmis.org> > To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com> > Cc: "Linus Torvalds" <torvalds@linux-foundation.org>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, "Huang Ying" > <ying.huang@intel.com>, "Lai Jiangshan" <laijs@cn.fujitsu.com>, "Lai Jiangshan" <eag0628@gmail.com>, "Peter > Zijlstra" <peterz@infradead.org>, "LKML" <linux-kernel@vger.kernel.org>, "Ingo Molnar" <mingo@kernel.org> > Sent: Friday, March 6, 2015 2:03:47 PM > Subject: Re: Possible lock-less list race in scheduler_ipi() > > On Fri, 6 Mar 2015 14:35:23 +0000 (UTC) > Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote: > > > > Indeed, the compiler should never reorder loads/stores from/to > > same memory location from a program order POV. What I had in mind > > is a bit more far-fetched though: it would involve having the compiler > > reorder this load after a store to another memory location, which > > would in turn allow another execution context (interrupt or thread) > > to corrupt the list. > > You mean on another CPU? Because the code you are worried about has > interrupts disabled.
I'm worried that another CPU could issue try_to_wake_up() on a task concurrently with the llist iteration within sched_ttwu_pending().
AFAIU, ttwu_queue_remote() is called from ttwu_queue() without holding the rq lock. So I'm wondering what prevents corruption of the wake_list in this situation.
Thanks,
Mathieu
-- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
| |