Joe Eykholt wrote: > Mike Christie wrote: >> Mike Christie wrote: >>>> As you mentioned that there were issues like this prior to shared >>>> tag map fix in libfc, therefore not sure on reverting shared tag map >>>> fix from libfc with added over head of maintaining link list of >>> I think we agree we need a way to loop over running commands for error >>> handling operations. Are you saying you want to keep the shared tag map >>> way of looking up commands? My issue with the shared tag map is if we >>> absolutely needed to go from some unique tag to some struct then a look >>> up table is great. >>> >>> However, if there is any way we can not have to use that code I would >>> prefer it. Using it to just loop over the running commands is really >>> ugly and more difficult than it needs to be. We have to handle the cases >>> where the tag is mapped to a fc_fcp_pkt (normal case), the tag is >>> allocated but not yet mapped to a fc_fcp_pkt (in this case the scsi mid >>> layer is either cleaning up the command because we called scsi_done on >>> it, or scsi-ml has allocated a tag and associated it with a scsi_cmnd, >>> but has not yet called fc_queuecommand). We also have to worry about the >>> cases where the tag is reused and the scsi-ml eh is running, but I think >>> that should be handled by the first two cases (at least that is how I >>> worked it out) - I do not like having to worry about it though. >>> >> Oh yeah, we actually had this discussion for iscsi a while back. We need >> to be able to loop over the running commands to cleanup lun and target >> resets, and for when a session goes bad and we need to return the >> commands back to scsi-ml. >> >> For the scsi eh paths, scsi_error.c actually has a list of commands that >> need cleaning up, so we could modify scsi_error to pass us a list of >> commands to work on. >> >> For transport class paths though, I am not sure what to do. For example >> for fc when the rport is deleted and eventualy when the fast io fail or >> dev loss tmo fire we will want to cleanup commands in the terminate >> rport io callouts (that is if we decide not to just cleanup them up when >> the rport is deleted like how qla2xxx does it (ignoreing tape >> commands)). Unfornately the classes do not maintain a list for us like >> scsi_error.c. If we could figure something out though we could fix this >> issue in a lot of drivers. Do you guys have any tricks? >> _______________________________________________ >> devel mailing list >> [email protected] >> http://www.open-fcoe.org/mailman/listinfo/devel > > The exchange manager reset function should help here. It should call > the response handler for any open exchanges. It isn't currently > being used when a remote port goes away, but that is easy to change. > > I sent Mike a similar message. >
Ah that should work. Thanks. If you guys merge this patch, then I will send a patch to scsi-ml for the scsi_error.c changes. When that is okd I will just replace the lists then. _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
