Re: [Bug #32982] Kernel locks up a few minutes after boot

From: Jens Axboe
Date: Tue Apr 19 2011 - 13:06:26 EST


On 2011-04-19 18:48, Christoph Hellwig wrote:
>> + blk_run_queue_async(sdev->request_queue);
>
> This doesn't even have to be async except when scsi drivers call
> cmd->scsi_done directly. It seems like if this always went through the
> softirq (or kblockd) we could still run it in context for the others.

Exactly. I'll pass an 'optimize' patch past James.

>> + /*
>> + * This get/put dance makes no sense
>> + */
>> get_device(&rport->dev);
>> -
>> - spin_lock_irqsave(rport->rqst_q->queue_lock, flags);
>> - flagset = test_bit(QUEUE_FLAG_REENTER, &rport->rqst_q->queue_flags) &&
>> - !test_bit(QUEUE_FLAG_REENTER, &rport->rqst_q->queue_flags);
>> - if (flagset)
>> - queue_flag_set(QUEUE_FLAG_REENTER, rport->rqst_q);
>> - __blk_run_queue(rport->rqst_q);
>> - if (flagset)
>> - queue_flag_clear(QUEUE_FLAG_REENTER, rport->rqst_q);
>> - spin_unlock_irqrestore(rport->rqst_q->queue_lock, flags);
>> -
>> + blk_run_queue_async(rport->rqst_q);
>
> And the QUEUE_FLAG_REENTER mess here never made sense either as it
> tested for a bit beeing set and not set at the same time. So this one
> actually should be able to be replaced by a plain blk_run_queue.

Yep, it's completely broken as-is.

--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/