On 04/06/2012 04:24 AM, Bart Van Assche wrote: > On 04/05/12 21:29, Mike Christie wrote: > >> Tomas's bug occurs when drivers use scsi_scan_host, use the async scsi >> device scanning, and then rmmod the LLD while the scan is still in progress. >> >> I think a general problem that we might hit similar to Tomas's issue is >> when scanning from userspace then rmmoding the driver. Maybe that means >> we need a more generic fix? Or, maybe that could be handled by having >> scsi_scan() do a try_module_get before scanning. > > That suggestion certainly makes sense to me. But Tomas' approach has the > advantage that it guarantees that scanning will have finished once > scsi_remove_hosts() returned and hence has less potential for triggering > race conditions than an approach based on try_module_get(). 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. -- 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
