aboutsummaryrefslogtreecommitdiffstats
path: root/include/acpi
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2013-02-13 08:36:47 -0500
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2013-02-13 08:36:47 -0500
commit3757b94802fb65d8f696597a74053cf21738da0b (patch)
tree78a3a00dbd82fab5e30a46699f83a3e492604e86 /include/acpi
parent64fd7401c5e4cf7c64452ecd9b700a55a5ebea50 (diff)
ACPI / hotplug: Fix concurrency issues and memory leaks
This changeset is aimed at fixing a few different but related problems in the ACPI hotplug infrastructure. First of all, since notify handlers may be run in parallel with acpi_bus_scan(), acpi_bus_trim() and acpi_bus_hot_remove_device() and some of them are installed for ACPI handles that have no struct acpi_device objects attached (i.e. before those objects are created), those notify handlers have to take acpi_scan_lock to prevent races from taking place (e.g. a struct acpi_device is found to be present for the given ACPI handle, but right after that it is removed by acpi_bus_trim() running in parallel to the given notify handler). Moreover, since some of them call acpi_bus_scan() and acpi_bus_trim(), this leads to the conclusion that acpi_scan_lock should be acquired by the callers of these two funtions rather by these functions themselves. For these reasons, make all notify handlers that can handle device addition and eject events take acpi_scan_lock and remove the acpi_scan_lock locking from acpi_bus_scan() and acpi_bus_trim(). Accordingly, update all of their users to make sure that they are always called under acpi_scan_lock. Furthermore, since eject operations are carried out asynchronously with respect to the notify events that trigger them, with the help of acpi_bus_hot_remove_device(), even if notify handlers take the ACPI scan lock, it still is possible that, for example, acpi_bus_trim() will run between acpi_bus_hot_remove_device() and the notify handler that scheduled its execution and that acpi_bus_trim() will remove the device node passed to acpi_bus_hot_remove_device() for ejection. In that case, the struct acpi_device object obtained by acpi_bus_hot_remove_device() will be invalid and not-so-funny things will ensue. To protect agaist that, make the users of acpi_bus_hot_remove_device() run get_device() on ACPI device node objects that are about to be passed to it and make acpi_bus_hot_remove_device() run put_device() on them and check if their ACPI handles are not NULL (make acpi_device_unregister() clear the device nodes' ACPI handles for that check to work). Finally, observe that acpi_os_hotplug_execute() actually can fail, in which case its caller ought to free memory allocated for the context object to prevent leaks from happening. It also needs to run put_device() on the device node that it ran get_device() on previously in that case. Modify the code accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
Diffstat (limited to 'include/acpi')
-rw-r--r--include/acpi/acpi_bus.h3
1 files changed, 3 insertions, 0 deletions
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 41850cb21730..227ba7dc293d 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -395,6 +395,9 @@ int acpi_bus_receive_event(struct acpi_bus_event *event);
395static inline int acpi_bus_generate_proc_event(struct acpi_device *device, u8 type, int data) 395static inline int acpi_bus_generate_proc_event(struct acpi_device *device, u8 type, int data)
396 { return 0; } 396 { return 0; }
397#endif 397#endif
398
399void acpi_scan_lock_acquire(void);
400void acpi_scan_lock_release(void);
398int acpi_scan_add_handler(struct acpi_scan_handler *handler); 401int acpi_scan_add_handler(struct acpi_scan_handler *handler);
399int acpi_bus_register_driver(struct acpi_driver *driver); 402int acpi_bus_register_driver(struct acpi_driver *driver);
400void acpi_bus_unregister_driver(struct acpi_driver *driver); 403void acpi_bus_unregister_driver(struct acpi_driver *driver);