public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Scheduler Bug (set_cpus_allowed)
@ 2002-06-06 23:20 Mike Kravetz
  2002-06-07 18:36 ` Robert Love
  0 siblings, 1 reply; 24+ messages in thread
From: Mike Kravetz @ 2002-06-06 23:20 UTC (permalink / raw)
  To: Robert Love, Ingo Molnar, linux-kernel

At my suggestion the following optimization/fast path
was added to set_cpus_allowed:

        /*
         * If the task is not on a runqueue, then it is sufficient
         * to simply update the task's cpu field.
         */
        if (!p->array) {
                p->thread_info->cpu = __ffs(p->cpus_allowed);
                task_rq_unlock(rq, &flags);
                goto out;
        }

Unfortunately, the assumption made here is not true.

Consider the case where a task is to give up the CPU
and schedule() is called.  In such a case the current
task is removed from the runqueue (via deactivate_task).
Now, further assume that there are no runnable tasks
on the runqueue and we end up calling load_balance().
In load_balance, we potentially drop the runqueue lock
to obtain multiple runqueue locks in the proper order.
Now, when we drop the runqueue lock we will still
be running in the context of task p.  However, p does
not reside on a runqueue.  It is now possible for
set_cpus_allowed() to be called for p.  We can get the
runqueue lock and take the fast path to simply update
the task's cpu field.  If this happens, bad (very bad)
things will happen!

My first thought was to simply add a check to the
above code to ensure that p was not currently running
(p != rq->curr).  However, even with this change I
'think' the same problem exists later on in schedule()
where we drop the runqueue lock before doing a context
switch.  At this point, p is not on the runqueue and
p != rq->curr, yet we are still runnning in the context
of p until we actually do the context switch.  To tell
the truth, I'm not exactly sure what 'rq->frozen' lock
is for.  Also, the routine 'schedule_tail' does not
appear to be used anywhere.

Comments?/Thoughts?/Suggestions?
-- 
Mike

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2002-06-13 22:08 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-06-06 23:20 Scheduler Bug (set_cpus_allowed) Mike Kravetz
2002-06-07 18:36 ` Robert Love
2002-06-07 19:12   ` Mike Kravetz
2002-06-10 20:12     ` Ingo Molnar
2002-06-10 20:57       ` Mike Kravetz
2002-06-10 22:35         ` Ingo Molnar
2002-06-10 23:15           ` Mike Kravetz
2002-06-10 23:24             ` Ingo Molnar
2002-06-10 23:28               ` Robert Love
2002-06-11  0:05                 ` [patch] current scheduler bits, 2.5.21 Ingo Molnar
2002-06-11  0:27                   ` Robert Love
2002-06-11 17:35                     ` [patch] current scheduler bits #2, 2.5.21 Ingo Molnar
2002-06-11 18:25                       ` Robert Love
2002-06-11 18:33                         ` [patch] current scheduler bits #3, 2.5.21 Ingo Molnar
2002-06-13 21:26                           ` [PATCH] " Robert Love
2002-06-13 22:06                             ` [patch] current scheduler bits #4, 2.5.21 Ingo Molnar
2002-06-07 23:20   ` Scheduler Bug (set_cpus_allowed) J.A. Magallon
2002-06-12  0:00     ` Andrea Arcangeli
2002-06-10 18:50   ` Mike Kravetz
2002-06-10 20:02     ` Ingo Molnar
2002-06-12 11:54       ` David S. Miller
2002-06-12 16:57         ` [patch] switch_mm()'s desire to run without the rq lock Ingo Molnar
2002-06-12 21:54           ` David S. Miller
2002-06-12 22:31           ` David S. Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox