summaryrefslogtreecommitdiffstats
path: root/include/acpi
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2013-08-28 21:41:07 +0200
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2013-08-29 22:01:16 +0200
commitf943db40c29f3c82a56956e9ca36f21d6d855db9 (patch)
tree18ed60632fcdc79f91006f733b49681929988708 /include/acpi
parentdriver core / ACPI: Avoid device hot remove locking issues (diff)
downloadlinux-f943db40c29f3c82a56956e9ca36f21d6d855db9.tar.xz
linux-f943db40c29f3c82a56956e9ca36f21d6d855db9.zip
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: Gu Zheng <guz.fnst@cn.fujitsu.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Toshi Kani <toshi.kani@hp.com>
Diffstat (limited to 'include/acpi')
-rw-r--r--include/acpi/acpi_bus.h3
1 files changed, 1 insertions, 2 deletions
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 94383a70c1a3..6ff9510718d7 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -157,9 +157,8 @@ struct acpi_device_flags {
u32 removable:1;
u32 ejectable:1;
u32 power_manageable:1;
- u32 eject_pending:1;
u32 match_driver:1;
- u32 reserved:26;
+ u32 reserved:27;
};
/* File System */