Jens Axboe wrote:
>>>>2.5.27:drivers/block/ll_rw_blk.c
>>>>void blk_start_queue(request_queue_t *q)
>>>>{
>>>> if (test_and_clear_bit(QUEUE_FLAG_STOPPED, &q->queue_flags)) {
>>>> unsigned long flags;
>>>>
>>>> spin_lock_irqsave(q->queue_lock, flags);
>>>> if (!elv_queue_empty(q))
>>>> q->request_fn(q);
>>>> spin_unlock_irqrestore(q->queue_lock, flags);
>>>> }
>>>>}
> There were buggy versions at one point, however they may not have made it
> into a full release. In that case it was just bk version of 2.5.19-pre
> effectively. I forget the details :-)
Naj - it's far more trivial I just looked at wrong tree at hand...
But anyway. What happens if somone does set QUEUE_FLAG_STOPPED
between the test_and_claer_bit and taking the spin_lock? Setting
the QUEUE_FLAG_STOPPED isn't maintaining the spin_lock protection!
My goal is to make sure that the QUEUE_FLAG_STOPPED has a valid value
*inside* the q->request_fn call.
This here is where it's supposed to be set:
void blk_stop_queue(request_queue_t *q)
{
unsigned long flags;
spin_lock_irqsave(q->queue_lock, flags);
blk_remove_plug(q);
spin_unlock_irqrestore(q->queue_lock, flags);
set_bit(QUEUE_FLAG_STOPPED, &q->queue_flags);
}
And I don't see anything preventing the above problem.
It sould perhaps be?
void blk_stop_queue(request_queue_t *q)
{
unsigned long flags;
spin_lock_irqsave(q->queue_lock, flags);
blk_remove_plug(q);
set_bit(QUEUE_FLAG_STOPPED, &q->queue_flags); /* Notice
spinlock still held! */
spin_unlock_irqrestore(q->queue_lock, flags);
}
void blk_start_queue(request_queue_t *q)
{
if (test_bit(QUEUE_FLAG_STOPPED, &q->queue_flags)) {
unsigned long flags;
spin_lock_irqsave(q->queue_lock, flags);
if (!test_bit(QUEUE_FLAG_STOPPED, &q->queue_flags)) {
spin_unlock_irqsave(q->queue_lock, flags);
return;
}
clear_bit(QUEUE_FLAG_STOPPED, &q->queue_flags);
if (!elv_queue_empty(q))
q->request_fn(q);
spin_unlock_irqrestore(q->queue_lock, flags);
}
}
At least I couldn't see any harm in doing it like above.
And again. I think it would assert that the flag is well defined inside
q->request_fn().
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 30 2002 - 14:00:15 EST