On Thu, 2005-06-16 at 00:31 -0700, Mike Anderson wrote: > I have something similar that I was testing since you mentioned the > problem the other day. Our build machine went down so I will need to wait > until tomorrow to get access to my patches for a post, if you have already > rolled a patch we can compare notes when I post. > > What I did in the patch sequence was: > 1.) Recode the scsi_host state model to align with the device > state model (i.e. added scsi_host_set_state function and > associated changes). > 2.) Made shost cancel matched the scsi device state model and set > this at the top of scsi_remove_host. Previous cancel code was not > doing anything as the list was normally empty do to > scsi_forget_host being called first. Also there where possible > race conditions that you previously mentioned about canceling > commands in this method. > 3.) Added choke point checks under the scan_mutex to determine if > scanning is allowed (scsi_host_scan_allowed). > 4.) Added a target state model to match the scsi device state > model. > 5.) I use the STGT_CANCEL and STGT_DEL states in scsi_forget_host > to skip over entries in the list as I am no longer using the > _safe version. > This looks like a good starting point with limited testing. I also need to > more states to the target state model as I only added a few that I needed > for the delete code. That sounds something like what I was thinking. There is some subtlety to this: the call to forget host with existing targets must: a) put the host into a state where it won't accept any additions or removal. b) loop over targets and devices removing them from visibility and doing final puts for them c) finally remove the host from visibility, set the deleted state and do the final put (which may not remove the actual structure until the last referrer relinquishes its reference). Also, since the target is a pure container, I don't think it needs to be a party to the state model. Anyway, post the code and we can refine it. James - : 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
