Hi Tejun, On Thu, Sep 3, 2015 at 6:19 PM, Tejun Heo <tj@xxxxxxxxxx> wrote: > 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. My point is that you cannot get into that situation. If hotplug already holds device_hotplug_lock, the write to "online" will end up doing restart_syscall(). If the "online" code path is holding the lock, hotplug cannot acquire it and cannot proceed. Am I missing anything? Thanks, Rafael -- 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
