Re: [RFC] How to fix an async scan - rmmod race?

[Bart Van Assche <bvanassche@acm.org>]

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.