lkml.org 
[lkml]   [2000]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjecttest9: running tasks not in run-queue
I have been playing around with the scheduler in the test9
kernel and noticed that it sometimes chooses tasks to run
that are not on the run-queue. This may seem strange, but
here is how it happens

task A on processor 0, calls __lock_sock() which does the
following:

void __lock_sock(struct sock *sk)
{
DECLARE_WAITQUEUE(wait, current);

add_wait_queue_exclusive(&sk->lock.wq, &wait);
for(;;) {
current->state = TASK_EXCLUSIVE | TASK_UNINTERRUPTIBLE;
spin_unlock_bh(&sk->lock.slock);
schedule();
spin_lock_bh(&sk->lock.slock);
if(!sk->lock.users)
break;
}
current->state = TASK_RUNNING;
remove_wait_queue(&sk->lock.wq, &wait);
}

Now when __lock_sock calls schedule, the task's state is set
as above and the following scheduler code removes the task from
the run-queue.

switch (prev->state & ~TASK_EXCLUSIVE) {
case TASK_INTERRUPTIBLE:
if (signal_pending(prev)) {
prev->state = TASK_RUNNING;
break;
}
default:
del_from_runqueue(prev);
case TASK_RUNNING:
}

After the task is removed from the run-queue, an interrupt is
serviced on another CPU which ultimately calls __wake_up_common().
__wake_up_common() chooses task A to wakeup and best_exclusive is
is set to A. The following code in __wake_up_common() is then
executed:

if (best_exclusive)
best_exclusive->state = TASK_RUNNING;
wq_write_unlock_irqrestore(&q->lock, flags);

if (best_exclusive) {
if (sync)
wake_up_process_synchronous(best_exclusive);
else
wake_up_process(best_exclusive);
}

Note that the state of task A will then be set to TASK_RUNNING.
Now back on CPU 1 (where we are in the scheduler routine) we
perform the following test:

if (prev->state == TASK_RUNNING)
goto still_running;

Since the state of prev has been changed to TASK_RUNNING by the
__wake_up_common code, we set next = prev. This means that we
potentially choose to continue running the current task, even
though the task has been deleted from the run-queue.

Now, what usually happens is that wake_up_process_synchronous or
wake_up_process will add the task back to the run-queue as soon
as the scheduler drops the run-queue lock. Therefore, this does
not seem to cause any problems.

I'm curious, is this behavior by design OR are we just getting
lucky?

Thanks,
--
Mike Kravetz mkravetz@sequent.com
IBM Linux Technology Center
15450 SW Koll Parkway
Beaverton, OR 97006-6063 (503)578-3494
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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