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
