On 06/26/12 07:19, James Bottomley wrote: > On Mon, 2012-06-25 at 17:05 -0500, Mike Christie wrote: >> Only the scsi_tgt_lib.c code uses the uses the uspace_req_q. That code >> does not use it in a traditional way. It passes __scsi_alloc_queue NULL >> for the request_fn function argument, so this request queue does not >> have a function that pulls requests off a queue like is done for the >> initiator path. >> >> That target code mostly uses the queue struct so that it can use the >> block/scsi functions that need a request queue to build scatterlists, >> cmds, bios, etc. When that code was made originally we were going to use >> the queue in a more tradition way or break out the queue limits into >> another struct and pass them around. I think we have the latter now, but >> the target code has not been converted. >> >> But so that is why we cannot hit a race like you are thinking about in >> the initiator path. >> >> It is also a weird use of the queue so it is also why it does not make >> sense :) > > OK, could we encapsulate all that in the comment so I don't have to ask > again in a year's time ... ? Maybe it's easier to implement Tejun's suggestion (swapping the blk_cleanup_queue() call and freeing the queuedata) ? That should be readable for everyone and shouldn't need a comment. Bart. -- 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
