On 04/08/2012 12:38 PM, Bart Van Assche wrote: > On 04/06/12 17:15, James Bottomley wrote: > >> Consider where the command came from: either it's come from startup (the >> current problem), operation (in which case the device must be open to >> send and receive it) or teardown (which is synchronous). > > > And what about e.g. sd_check_events() or sr_check_events() ? Are those setup to run from the open functions, so we will have done a get on the module (sd_open() -> check_disk_change()) for those. > > Maybe I should explain why I started looking at the SCSI error handler > in so much detail. While running disk removal tests against ib_srp I > found out that the SCSI error handler thread can invoke the LLD's abort > and reset handlers long after scsi_remove_host() finished. That's why I > came up with this patch: "[PATCH 05/15] ib_srp: Avoid that SCSI error > handling triggers a crash" > (http://www.mail-archive.com/linux-rdma@xxxxxxxxxxxxxxx/msg11234.html). > But I'm still wondering whether that's the right approach. Should this > issue be addressed in each LLD or in the SCSI core ? > I would like scsi core to handle this, but I think right now drivers are doing work arounds like your patch. For example FC drivers will call fc_remove_host which sets things up so no new IO can be sent to the device after that function has completed and will call some callouts like dev_loss_tmo_callbk to cleanup outstanding IO. The problem is that when it calls scsi_remove_host that could cause commands like cache sync from sd.c's shutdown to get failed (the queuecommand function will call the fc check ready function which will fail the IO immediately). iSCSI drivers will call scsi_remove_target, do a iscsi logout and cleanup outstanding commands if needed, set things up so new IO is failed (I do not think there should be new IO because scsi_remove_target should have removed the devices and the iscsi logout/shutdown code made sure the iscsi queues were empty), then call scsi_remove_host. -- 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
