Files
linux/kernel
Oleg Nesterov cc28db4642 sched: sched_exec(): Remove the select_fallback_rq() logic
commit 30da688ef6 upstream.

sched_exec()->select_task_rq() reads/updates ->cpus_allowed lockless.
This can race with other CPUs updating our ->cpus_allowed, and this
looks meaningless to me.

The task is current and running, it must have online cpus in ->cpus_allowed,
the fallback mode is bogus. And, if ->sched_class returns the "wrong" cpu,
this likely means we raced with set_cpus_allowed() which was called
for reason, why should sched_exec() retry and call ->select_task_rq()
again?

Change the code to call sched_class->select_task_rq() directly and do
nothing if the returned cpu is wrong after re-checking under rq->lock.

From now task_struct->cpus_allowed is always stable under TASK_WAKING,
select_fallback_rq() is always called under rq-lock or the caller or
the caller owns TASK_WAKING (select_task_rq).

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <20100315091019.GA9141@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-09-20 13:18:08 -07:00
..
2010-08-13 13:19:50 -07:00
2009-12-18 14:03:52 -08:00
2009-06-24 00:02:38 -04:00
2010-09-20 13:18:03 -07:00
2009-09-18 09:48:52 -07:00
2008-10-16 11:21:30 -07:00
2009-08-29 14:10:07 +02:00
2008-07-28 14:37:38 +02:00
2009-09-19 13:13:17 -07:00
2009-05-15 07:56:24 -05:00
2009-07-24 10:53:29 +02:00
2010-07-05 11:10:31 -07:00
2009-01-14 18:09:02 +01:00
2009-06-18 13:03:56 -07:00
2009-10-29 08:56:20 +10:30
2008-09-02 19:21:40 -07:00
2010-05-26 14:29:18 -07:00
2009-10-07 08:11:20 +02:00
2009-09-23 07:39:41 -07:00
2008-02-06 10:41:02 -08:00
2009-07-12 14:03:27 -07:00
2009-09-23 18:13:10 -07:00
2009-11-02 16:02:39 +01:00
2009-06-18 13:03:55 -07:00