On Fri, Nov 20, 2015 at 10:26 AM, James Bottomley
<[email protected]> wrote:
>
> We can look at it, but the analysis shouldn't be correct. This device
> is the one we first used to issue the report lun scan. Either it's an
> existing device, or we created it specially for the purpose. If it's an
> existing one, that put just releases our reference, but the core still
> has one (there'd have to be a very unusual scan destroy race for the
> core to be releasing a reference to an object it was in process of
> scanning).
Side note: that whole "if it's an existing one" looks fundamentally racy.
What if two threads have that existing one, and both threads decide
"there's no device there", so they'll both decide to do that
__scsi_remove_device()?
In fact, one of the threads might have created the device, so it looks
like it's sufficient that just one thread has that
"scsi_device_lookup_by_target()" case..
I don't see any serialization around this.
Now, I do agree that it's odd that this happens during early kernel
initcalls, but the scsi layer is one of the things that uses async
stuff, so if that do_scan_async() ever ends up using the same target
twice, that would explain it. Can that happen some way?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
