On Saturday, November 30, 2013 12:38:26 AM Rafael J. Wysocki wrote: > On Tuesday, November 26, 2013 06:26:54 PM Yinghai Lu wrote: > > On Tue, Nov 26, 2013 at 5:24 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > > > > > > So assume pci_destroy_dev() is called twice in parallel for the same dev > > > by two different threads. Thread 1 does the atomic_inc_and_test() and > > > finds that it is OK to do the device_del() and put_device() which causes > > > the device object to be freed. Then thread 2 does the atomic_inc_and_test() > > > on the already freed device object and crashes the kernel. > > > > > thread2 should still hold one extra reference. > > that is in > > device_schedule_callback > > ==> sysfs_schedule_callback > > ==> kobject_get(kobj) > > > > pci_destroy_dev for thread2 is called at this point. > > > > and that reference will be released from > > sysfs_schedule_callback > > ==> kobject_put()... > > Well, that would be the case if thread 2 was started by device_schedule_callback(), > but again, for example, it may be trim_stale_devices() started by acpiphp_check_bridge() > that doesn't hold extra references to the pci_dev. [Well, that piece of code > is racy anyway, because it walks bus->devices without locking. Which is my > fault too, because I overlooked that. Shame, shame.] > > Perhaps we can do something like the (untested) patch below (in addition to the > $subject patch). Do you see any immediate problems with it? Ah, I see one. It will break pci_stop_bus_device() and pci_remove_bus_device(). So much for being clever. Moreover, it looks like those two routines above are racy too for the same reason? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
