Hello, Rafael. On Thu, Sep 03, 2015 at 02:58:16AM +0200, Rafael J. Wysocki wrote: > So acpi_device_hotplug() calls lock_device_hotplug() which simply > acquires device_hotplug_lock. It is held throughout the entire > hot-add/hot-remove code path. > > Witing anything to /sys/devices/system/cpu/cpux/online goes through > online_store() in drivers/base/core.c and that does > lock_device_hotplug_sysfs() which then attempts to acquire > device_hotplug_lock using mutex_trylock(). And it only calls > either device_online() or device_offline() if it ends up with the > lock held. > > Quite frankly, I don't see how these particular two code paths can > deadlock in any way. > > So either a third code path is involved which is not executed > under device_hotplug_lock, or lockdep needs to be told to actually > take device_hotplug_lock into account in this case IMO. Hmm... all sysfs rw functions are protected from removal. ie. by default, removal of a sysfs file drains in-flight rw operations, so the hot plug path grabs a lock and then tries to remove a file and writing to the online file makes the file's write method to try to grab the same lock. It deadlocks if the hotunplug path already has the lock and trying to drain the online file for removal. The same problem exists for "delete" files but that's already handled from device core side. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
