Re: please DON'T run 2.5.27 with IDE!

[Marcin Dalecki <dalecki@evision.ag>]

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);
         }
}