ACPI / hotplug: Remove containers synchronously
The current protocol for handling hot remove of containers is very fragile and causes acpi_eject_store() to acquire acpi_scan_lock which may deadlock with the removal of the device that it is called for (the reason is that device sysfs attributes cannot be removed while their callbacks are being executed and ACPI device objects are removed under acpi_scan_lock). The problem is related to the fact that containers are handled by acpi_bus_device_eject() in a special way, which is to emit an offline uevent instead of just removing the container. Then, user space is expected to handle that uevent and use the container's "eject" attribute to actually remove it. That is fragile, because user space may fail to complete the ejection (for example, by not using the container's "eject" attribute at all) leaving the BIOS kind of in a limbo. Moreover, if the eject event is not signaled for a container itself, but for its parent device object (or generally, for an ancestor above it in the ACPI namespace), the container will be removed straight away without doing that whole dance. For this reason, modify acpi_bus_device_eject() to remove containers synchronously like any other objects (user space will get its uevent anyway in case it does some other things in response to it) and remove the eject_pending ACPI device flag that is not used any more. This way acpi_eject_store() doesn't have a reason to acquire acpi_scan_lock any more and one possible deadlock scenario goes away (plus the code is simplified a bit). Reported-and-tested-by: NGu Zheng <guz.fnst@cn.fujitsu.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
Showing
想要评论请 注册 或 登录