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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Fri, 2012-04-06 at 16:15 +0000, Bart Van Assche wrote:
> On 04/06/12 15:20, James Bottomley wrote:
> 
> > On Fri, 2012-04-06 at 11:54 +0200, Tomas Henzl wrote:
> >> I like this idea(try_module_get) it is easy/elegant and it is used in scsi_rescan_device,
> >> but a scan can take a lot of time and during that time the driver couldn't be removed.
> >> When a flag in scsi_remove_host is set then the scan can be cancelled, if the user 
> >> rmmods the driver.
> > 
> > This is my preferred solution too.  The rule for async stuff is either
> > cancel or wait and since we can't cancel, we need to ensure the wait by
> > holding the module until the async event has finished.
> > 
> > Since the whole of the host scan must complete, we need to hold the
> > module across that, but I bet we also need to hold it across user
> > triggered target scans as well.
> 
> 
> As far as I can see the queuecommand call in scsi_dispatch_cmd() can
> race with module removal - that call can be triggered while the host
> template is being unloaded. I'm not sure though what the best approach
> is to fix that race.

Um, it's a bit hard to see how.  It's not really possible to trigger
queuecommand except in the initial probe without an open device ... and
opening the device holds the module.

James