I am looking again at how and when a FC LLD should call fc_remote_port_delete. Some help would be welcome to cover all requirements and to plug the holes... One scenario i am looking at: The connection to the HBA has been temporarily lost and the LLD has to return all pending I/O requests to the upper layers, so they can be retried later. Now with the SCSI device being part of a multipath device, the first failed I/O request triggers path failover: multipath_end_io do_end_io fail_path queue_work(kmultipathd, &pgpath->deactivate_path); which then marks the following returned requests as timed out: deactivate_path blk_abort_queue blk_abort_request blk_rq_timed_out scsi_times_out fc_timed_out If the remote_port status is not BLOCKED, this will trigger the SCSI midlayer error handling which cannot do much during the interruption to the hardware and will mark the SCSI devices 'offline'. In order to prevent this, the rule would be: First call fc_remote_port_delete to set the remote port (or in the case of an HBA interruption all remote ports) to BLOCKED, and only after this step call scsi_done to pass the SCSI commands back to the upper layers. This means, if the HBA problem is detected in interrupt context, fc_remote_port_delete has to be called before calling scsi_done. But the description for fc_remote_port_delete states: * Called from normal process context only - cannot be called from * interrupt. * * Notes: * This routine assumes no locks are held on entry. */ Looking at the functions called from fc_remote_port_delete, i don't see a problem in calling fc_remote_port_delete from interrupt context or with locks held. Does this mean the description should be fixed or am i missing something? fc_remote_port_add on the other hand can wait during flushes and has to be called from process context. To summarize: - A LLD has to call fc_remote_port_delete before returning SCSI commands from a failed port or failed HBA. - fc_remote_port_delete can be called from interrupt context before calling scsi_done if necessary - fc_remote_port_add has to be called from process context - The LLD has to serialize the fc_remote_port_add and fc_remote_port_delete calls to guarantee the add->delete->... sequence. -- Christof -- 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