On Mon, May 11, 2015 at 10:54:30AM +0200, Bart Van Assche wrote: > Hello Christoph, > > There are multiple events that can cause the SRP initiator driver to > initiate a reconnect: > 1. The SCSI core invoking eh_host_reset_handler(). > 2. An error reported by the IB HCA or by the IB core, e.g. an RDMA > transmit timeout or a transport layer disconnect reported by the > IB/CM. Right, I missed the srp_reconnect_work case. But even with that I think what I wrote above still stands. srp_reconnect_work in that case would just directly trigger the abort all commands and reconnect operation. The main point I was trying to make is that instead of having a sequence of: 1) block new queuecommand instances 2) flush out pending queuecommand instances 3) do part of the disconnect 4) fail all in-flight commands 5) reconnect we should aim for: 1) block new queuecommand instances 2) fail all in-flight commands 3) disconnect and reconnect to avoid the need to keep track of pending queuecommand instances, and instead re-use the existing infrastructure to fail all in-flight commands, which we have the infrastructure for, and which we need to do anyway. -- 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
