On Wed, Aug 28, 2013 at 03:51:41PM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> > > 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). > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> > Reported-by: Gu Zheng <guz.fnst@xxxxxxxxxxxxxx> Acked-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> -- 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
