Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1218554
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Possible deadlock related to CPU hotplug and kernfs |
| Date | 2015-09-03 22:10 +0200 |
| Message-ID | <q4IZA-5qs-11@gated-at.bofh.it> (permalink) |
| References | <q3O1k-819-9@gated-at.bofh.it> <q4iVs-1Ic-15@gated-at.bofh.it> <q4qJl-4mi-23@gated-at.bofh.it> <q4Fp0-dt-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi Tejun, On Thu, Sep 3, 2015 at 6:19 PM, Tejun Heo <tj@kernel.org> 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Possible deadlock related to CPU hotplug and kernfs Jiang Liu <jiang.liu@linux.intel.com> - 2015-09-01 09:20 +0200
Re: Possible deadlock related to CPU hotplug and kernfs Tejun Heo <tj@kernel.org> - 2015-09-02 18:20 +0200
Re: Possible deadlock related to CPU hotplug and kernfs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2015-09-03 02:40 +0200
Re: Possible deadlock related to CPU hotplug and kernfs Tejun Heo <tj@kernel.org> - 2015-09-03 18:20 +0200
Re: Possible deadlock related to CPU hotplug and kernfs "Rafael J. Wysocki" <rafael@kernel.org> - 2015-09-03 22:10 +0200
Re: Possible deadlock related to CPU hotplug and kernfs Jiang Liu <jiang.liu@linux.intel.com> - 2015-09-04 09:30 +0200
Re: Possible deadlock related to CPU hotplug and kernfs "Rafael J. Wysocki" <rafael@kernel.org> - 2015-09-04 16:20 +0200
Re: Possible deadlock related to CPU hotplug and kernfs Jiang Liu <jiang.liu@linux.intel.com> - 2015-09-07 05:20 +0200
csiph-web