Bartlomiej Zolnierkiewicz wrote:
>>There are some nasty checks for it != NULL in the generic BIO code.
>
>
> No, there are no checks there.
Hello?:
[root@localhost block]# grep \>special *.c
elevator.c: !rq->waiting && !rq->special)
^^^^^^ This one is supposed to have the required barrier effect.
ll_rw_blk.c: if (req->special || next->special)
ll_rw_blk.c: rq->special = NULL;
ll_rw_blk.c: rq->special = data;
^^^^^^^ This one is me :-).
ll_rw_blk.c: || next->waiting || next->special)
[root@localhost block]#
>>>So look at ide.c for example.
>>
>>So look at drivers which call blk_start_queue() from within
>>q->request_fn context, which is, well, causing deliberate *recursion*.
>>
>
>
> Are you sure? If so they should first check whether queue is
> started/stopped, if they don't it is a bug.
void blk_start_queue(request_queue_t *q)
{
if (test_bit(QUEUE_FLAG_STOPPED, &q->queue_flags)) {
unsigned long flags;
================== possigle race here for qeue_flags BTW.
spin_lock_irqsave(q->queue_lock, flags);
clear_bit(QUEUE_FLAG_STOPPED, &q->queue_flags);
if (!elv_queue_empty(q))
q->request_fn(q);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If we call it from within request_fn then if this isn't recursion on the
kernel stack then I don't know...
spin_unlock_irqrestore(q->queue_lock, flags);
}
}
-
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