James Smart wrote: > Why does your LLD need to reach up into the block layer to find an i/o ? > > Even if you are using tags as an index into something... I would think that > having to go up to the blk layer to retrieve a something that should have > already been known lower in the driver leaves room for race conditions. > This is how the blk and scsi tag api work for queue based tagging. We have the scsi_find_tag() function which takes a scsi device and than calls blk_queue_find_tag to get the request. It then does all the magic sdev to request_queue and request to scsi command work and pass the LLD the scsi command for the tag. So we can either add a driver array and do some tag to scsi command or driver stucture mapping or we can use the array already created in the scsi host block queue tag. And as you see Dave's patch did the latter in the spirit of not duplicating what scsi-ml or the block layer already do. I think there are some basic races though. For example, scsi_request_fn calls blk_queue_start_tag with only the queue lock held and so if the request_fn was called for two devices on the same host at the same time they both could call find_first_zero_bit on the shared bqt->tag_map and end up getting the same tag. - 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
