On 05/05/2012 01:07 AM, Bart Van Assche wrote:
> On 05/04/12 20:32, Mike Christie wrote:
>
>> Oh not wait. I do not get the patch. After blk_cleanup_queue runs then
>> no IO should be running and no new IO can be queued can it?
>>
>>>> */
>>>> blk_cleanup_queue(q);
>>>> + blk_abort_queue(q);
>>>>
>>>> if (sdev->is_visible) {
>>>> if (scsi_device_set_state(sdev, SDEV_CANCEL) != 0)
>
>
> After blk_cleanup_queue() finished no new requests will be queued to a
> SCSI LLD. However, that function doesn't wait for already queued
> requests to finish. I have verified with ib_srp LLD that the\
It does for me. It is supposed to isn't it? For BLOCK FS requests
blk_drain_queue will wait for the q->in_flight counters to go to zero.
They get incremented at scsi_request_fn-> blk_start_request ->
blk_dequeue_request time and decremented in scsi_end_request ->
blk_end_request -> blk_end_bidi_request -> blk_finish_request ->
blk_put_request -> elv_completed_request. For BLOCK PC and other
requests there is the rq.count tracking.
I added some printk code in the blk_drain_queue loop, and if I force the
target to wait to complete a IO, then remove the device, blk_drain_queue
is looping until the IO is eventually completed.
> blk_abort_queue() call triggers the "SRP abort called" kernel log
> message generated by ib_srp when srp_abort() is called.
What type of IO is it?
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
