[lkml]   [2001]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.4.7p6 hang
On Wed, Jul 11, 2001 at 05:58:09PM +0200, Andrea Arcangeli wrote:
> this one I forgot to sumbit but here it is now for easy merging:
> --- 2.4.4aa3/kernel/sched.c.~1~ Sun Apr 29 17:37:05 2001
> +++ 2.4.4aa3/kernel/sched.c Tue May 1 16:39:42 2001
> @@ -674,8 +674,10 @@
> #endif
> spin_unlock_irq(&runqueue_lock);
> - if (prev == next)
> + if (prev == next) {
> + current->policy &= ~SCHED_YIELD;
> goto same_process;
> + }
> #ifdef CONFIG_SMP
> /*

I would like to second the need for this patch in the 'mainline' kernel.
Not too long ago, I came up with the following senario caused by this
bug. The scenario is based on the unmodified 2.4.4 scheduler.

- Task A calls sched_yield(), and the code in sys_sched_yield()
determines that a yield is in order and sets SCHED_YIELD in
the task's policy field and need_resched is set for this task.

- When Task A attempts to return to user land, schedule() will
be called (since need_resched was set). However, in this case
schedule() does not find a better task than A to run. Since
task A will continue to run, the 'same_process' goto is taken
in schedule(). Note that __schedule_tail() is not called, so
the SCHED_YIELD flag remains set in A when it continues to

- Task A then performs some operation which causes it to go into
a non-runnable state (such as calling nanosleep()). After setting
the state of Task A to something other than TASK_RUNNING, a call
to schedule() will be made. At this time Task A will be removed
from the runqueue (again note that SCHED_YIELD remains set in A).
Also, assume that there are no other runnable tasks so the idle
task is chosen to run next on this CPU.

- Now, after schedule() releases the runqueue lock the timer for
Task A fires and we call the wake_up code. This code path will
eventually call try_to_wake_up() which will set the state of A
to TASK_RUNNING, add A to the runqueue and call reschedule_idle()
for A.

- Note that we have not yet cleared the has_cpu field in A. Hence,
can_schedule() will never be true for task A. As a result, we
will not send an IPI to any other CPU. In effect, reschedule_idle()
is a noop.

- Now, we finally call __schedule_tail() for task A. After clearing
the SCHED_YIELD and has_cpu flags, we notice that the state of A
is TASK_RUNNING (it was set by try_to_wake_up()) and take the
needs_resched goto.

- The needs_resched block of code usually results in a call to
reschedule_idle for the task. However, the first line of code
in this block is:

* Avoid taking the runqueue lock in cases where
* no preemption-check is necessery:
if ((prev == idle_task(smp_processor_id())) ||
(policy & SCHED_YIELD))
goto out_unlock;

Since, the SCHED_YIELD flag was set in A when we entered this routine
we will not call reschedule_idle().

In this case, the CPU associated with task A is still idle yet we will
not schedule the task on the CPU. In addition, it is possible that at
this time ALL CPUs in the system could be idle. Hence, we would end up
with all CPUs idle while task A is on the runqueue. Not good!

Mike Kravetz
IBM Linux Technology Center
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:56    [W:0.070 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site