Re: Why timer interrupt is disabled?

[Alexandr Andreev <andreev@niisi.msk.ru>]

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?