Why timer interrupt is disabled?

Alexandr Andreev andreev at niisi.msk.ru
Fri May 25 21:31:18 EDT 2001

David Woodhouse wrote:

>Ah - but we're _not_ manipulating the requests on the request queue. We're 
>servicing the request at the head of the queue, which is a special case - 
>the queueing code knows that drivers are likely to be looking at the 
>request at the head of the queue even while the io_request_lock is not held.
>The kernel is not preemptively scheduled. Unless the first process 
>explicitly calls schedule(), it's not going to lose the CPU. Only processes 
>in user mode are scheduled from the timer IRQ.
Oh yeah, i've got it... you absolutely right, the flash driver will 
never support requests manipulating, so we can don't care about the 
io_request_lock holding, and kernel is really preemptively.
So, we can unlock the io_request_lock in ftl.c, but what about double 
unlocking? Or, do you want to lock it back after proceeding request :) 
Is there any conflicts, when we try to unlock already unlocked lock? 

More information about the linux-mtd mailing list