On Fri, 2015-11-20 at 12:54 -0800, Linus Torvalds wrote: > On Fri, Nov 20, 2015 at 10:26 AM, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> 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()? It's done under the scan mutex, so there can only be one thread in that code at once. James > 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 majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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
