On Thu, 7 Sep 2000, Andi Kleen wrote:
>On Thu, Sep 07, 2000 at 09:00:29AM -0700, Leonard N. Zubkoff wrote:
>> WaitQueue_T WaitQueueEntry = { current, NULL };
>> add_wait_queue(&Controller->CommandWaitQueue, &WaitQueueEntry);
>> current->state = TASK_UNINTERRUPTIBLE;
>> spin_unlock(&io_request_lock);
>> schedule();
>> current->state = TASK_RUNNING;
>> remove_wait_queue(&Controller->CommandWaitQueue, &WaitQueueEntry);
>> spin_lock_irq(&io_request_lock);
>>
>> Is the fix simply moving the spin_unlock right before the call to
>> add_wait_queue?
>
>When you do that you should probably change it to a spin_unlock_irq()
I didn't changed that because not doing __sti() is faster, because
schedule() waste time doing an __sti() unconditionally. By the time we'll
remove sti() from schedule() we'll add a debugging code that check the IF
in the CPU is disabled and that BUG in that case (and that won't happen
before 2.5.x when all the sleep_on will die).
However if you want to replace it with a spin_unlock_irq(&io_request_lock)
in prevision to the possible removal of sti() from schedule() go ahead :).
It's just not necessary right now (and I only addressed the deadlock
condition with the patch).
Andrea
-
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/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:30 EST