[lkml]   [2001]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch-2.4.1-ac10] unsetting TASK_RUNNING
John Levon wrote:
> On Tue, 13 Feb 2001, Tigran Aivazian wrote:
> > Hi Alan,
> >
> > The only case in schedule_timeout() which does not call schedule() does
> > set tsk->state = TASK_RUNNING explicitly before returning. Therefore, any
> > code which unconditionally calls schedule_timeout() (and, of course
> > schedule()) does not need to set TASK_RUNNING afterwards.
> >
> > I have seen some people setting this TASK_RUNNING incorrectly, based on a
> > mere observation that "official Linux kernel code does so" -- so the patch
> > below is not just an optimization but serves for education (i.e. to stop
> > people copying unnecessary code).
> I had a similar set of patches a while ago. I had several more unnecessary
> settings.
> At least Matthew Dharm as usb-storage maintainer wanted to keep his in. Of more
> concern IMHO were the drivers busy waiting by failing to reset current->state
> on each iteration - e.g. maestro2, maestro3.

There is one danger with unnecessary

current->state = TASK_RUNNING;

If it's executed in an interrupt or bottom half handler it can corrupt
the runqueue.

In schedule():
* goto recalculate
* interrupts reenabled, bottom half handler might run
* interrupts disabled
* goto repeat_schedule;
* prev->state==TASK_RUNNING --> goto still_running.

And now a process that's not on the runqueue might be choosen for
execution, and the next del_from_runqueue() corrupts the runqueue.

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 13:17    [W:0.036 / U:1.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site