On 04/06/12 17:22, Mike Christie wrote: > Tomas's approach works when scsi_scan_host and the async scsi scanning > is used. However, I was saying that I think we have a 2nd problem that > is similar to Tomas's issue but initiated from a different path and will > bypass Tomas's checks. The host async scanning code does not come into > play when scanning from userspace. In the user scan case we could end up > having: > > 1. A transport class or scsi_sysfs.c initiate a scan. > 2. A user could rmmod the LLD. > 3. The LLD will call the transport remove host if there is one and then > scsi_remove_host. > > Note that for fc_remove_host there are checks to flush the scanning > workqueue but we will bypass the scan workqueue flush checks since for > this case we are scanning from the user thread and not from the host's > workqueue the fc classes normally uses for scanning. > 4. scsi_remove_host would move right past Tomas's code, because the user > initiated scan does not set any of those host async bits Tomas's is > checking. > 5. The LLD would then get removed and we would hit the same problem > Tomas's described where the scanning code is now accessing invalid > scsi_host_template fields. Good catch. Has it already been considered to remove the sysfs scan (and other) attributes explicitly from inside scsi_remove_host() ? As far as I can see that would prevent this race to occur because it would force scsi_remove_host() to wait until the scan that was triggered from user space has finished. It would also prevent that other SCSI callbacks could be triggered from user space after scsi_remove_host() finished and before the associated devices are removed entirely. Bart. -- 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
