On 02/11/2014 03:01 PM, Christoph Hellwig wrote: > Hi Hannes, > > I'll need a little reminder how we came to the conclusion that the > cancel_delayed_work in scsi_put_command was safe and we didn't need > a cancel_delayed_work_sync or flush_delayed_work. I remember we had > that discussion, but it seems that same doesn't apply to the equivalent > call in the blk-mq codepath in my tree. If you remember anything that > might make my life debugging this a bit easier. > Well, _actually_ the cancel_delayed_work should be pointless; I've just added it as a terminal measure here. (It'd actually be an idea to insert a BUG_ON() here ...) Thing is whenever the eh_timeout thingie kicks in we most definitely know there's a command in flight, and hence scsi_command_put() should _never_ be called. Only after eh_abort has finished the command will be returned via scsi_command_put(), but then eh_abort is done for, too, and no item should remain in the workqueue. HTH. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
