| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <1409123489-11786-1-git-send-email-tianyu.lan@intel.com>
Date: Wed, 27 Aug 2014 15:11:29 +0800
From: Lan Tianyu <tianyu.lan@...el.com>
To: rjw@...ysocki.net, lenb@...nel.org, fengguang.wu@...el.com
Cc: Lan Tianyu <tianyu.lan@...el.com>, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org,
All applicable <stable@...r.kernel.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: [PATCH V3] ACPI / OSL: Make acpi_os_map_cleanup() use call_rcu() to avoid deadlocks
Deadlock is possible when CPU hotplug and evaluating ACPI method happen
at the same time.
During CPU hotplug, acpi_cpu_soft_notify() is called under the CPU hotplug
lock. Then, acpi_cpu_soft_notify() calls acpi_bus_get_device() to obtain
the struct acpi_device attached to the given ACPI handle. The ACPICA's
namespace lock will be acquired by acpi_bus_get_device() in the process.
Thus it is possible to hold the ACPICA's namespace lock under the CPU
hotplug lock.
Evaluating an ACPI method may involve accessing an operation region in
system memory and the associated address space will be unmapped under
the ACPICA's namespace lock after completing the access. Currently, osl.c
uses RCU to protect memory ranges used by AML. When unmapping them it
calls synchronize_rcu() in acpi_os_map_cleanup(), but that blocks
CPU hotplug by acquiring the CPU hotplug lock. Thus it is possible to
hold the CPU hotplug lock under the ACPICA's namespace lock.
This leads to deadlocks like the following one if AML accessing operation
regions in memory is executed in parallel with CPU hotplug.
INFO: task bash:741 blocked for more than 30 seconds.
Not tainted 3.16.0-rc5+ #671
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
bash D ffff88014e214140 0 741 716 0x00000080
ffff88009b9f3a10 0000000000000086 ffff88009dcfb840 ffff88009b9f3fd8
0000000000014140 0000000000014140 ffffffff81c18460 ffffffff81c40fc8
ffffffff81c40fcc ffff88009dcfb840 00000000ffffffff ffffffff81c40fd0
Call Trace:
[<ffffffff817a1b29>] schedule_preempt_disabled+0x29/0x70
[<ffffffff817a34fa>] __mutex_lock_slowpath+0xca/0x1c0
[<ffffffff817a360f>] mutex_lock+0x1f/0x2f
[<ffffffff810bc8cc>] get_online_cpus+0x2c/0x50
[<ffffffff8111bbd4>] synchronize_sched_expedited+0x64/0x1c0
[<ffffffff8111bb65>] synchronize_sched+0x45/0x50
[<ffffffff81431498>] acpi_os_map_cleanup.part.7+0x14/0x3e
[<ffffffff81795c54>] acpi_os_unmap_iomem+0xe2/0xea
[<ffffffff81795c6a>] acpi_os_unmap_memory+0xe/0x14
[<ffffffff814459bc>] acpi_ev_system_memory_region_setup+0x2d/0x97
[<ffffffff81459504>] acpi_ut_update_ref_count+0x24d/0x2de
[<ffffffff814596af>] acpi_ut_update_object_reference+0x11a/0x18b
[<ffffffff81459282>] acpi_ut_remove_reference+0x2e/0x31
[<ffffffff8144ffdf>] acpi_ns_detach_object+0x7b/0x80
[<ffffffff8144ef11>] acpi_ns_delete_namespace_subtree+0x47/0x81
[<ffffffff81440488>] acpi_ds_terminate_control_method+0x85/0x11b
[<ffffffff81454625>] acpi_ps_parse_aml+0x164/0x289
[<ffffffff81454da6>] acpi_ps_execute_method+0x1c1/0x26c
[<ffffffff8144f764>] acpi_ns_evaluate+0x1c1/0x258
[<ffffffff81451f86>] acpi_evaluate_object+0x126/0x22f
[<ffffffff8144d1ac>] acpi_hw_execute_sleep_method+0x3d/0x68
[<ffffffff8144d5cf>] ? acpi_hw_enable_all_runtime_gpes+0x17/0x19
[<ffffffff8144deb0>] acpi_hw_legacy_wake+0x4d/0x9d
[<ffffffff8144e599>] acpi_hw_sleep_dispatch+0x2a/0x2c
[<ffffffff8144e5cb>] acpi_leave_sleep_state+0x17/0x19
[<ffffffff8143335c>] acpi_pm_finish+0x3f/0x99
[<ffffffff81108c49>] suspend_devices_and_enter+0x139/0x560
[<ffffffff81109162>] pm_suspend+0xf2/0x370
[<ffffffff81107e69>] state_store+0x79/0xf0
[<ffffffff813bc4af>] kobj_attr_store+0xf/0x20
[<ffffffff81284f3d>] sysfs_kf_write+0x3d/0x50
[<ffffffff81284580>] kernfs_fop_write+0xe0/0x160
[<ffffffff81210f47>] vfs_write+0xb7/0x1f0
[<ffffffff81211ae6>] SyS_write+0x46/0xb0
[<ffffffff8114d986>] ? __audit_syscall_exit+0x1f6/0x2a0
[<ffffffff817a4ea9>] system_call_fastpath+0x16/0x1b
INFO: task async-enable-no:749 blocked for more than 30 seconds.
Not tainted 3.16.0-rc5+ #671
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
async-enable-no D ffff88014e254140 0 749 2 0x00000080
ffff88009de83bf0 0000000000000046 ffff88009b850000 ffff88009de83fd8
0000000000014140 0000000000014140 ffff880148305dc0 ffff880149804160
7fffffffffffffff 0000000000000002 0000000000000000 ffff88009b850000
Call Trace:
[<ffffffff817a1689>] schedule+0x29/0x70
[<ffffffff817a0b49>] schedule_timeout+0x1f9/0x270
[<ffffffff81284bfe>] ? __kernfs_create_file+0x7e/0xa0
[<ffffffff8128546b>] ? sysfs_add_file_mode_ns+0x9b/0x160
[<ffffffff817a36b2>] __down_common+0x93/0xd8
[<ffffffff817a376a>] __down_timeout+0x16/0x18
[<ffffffff8110546c>] down_timeout+0x4c/0x60
[<ffffffff81431f97>] acpi_os_wait_semaphore+0x43/0x57
[<ffffffff8145a8f4>] acpi_ut_acquire_mutex+0x48/0x88
[<ffffffff81435d1b>] ? acpi_match_device+0x4f/0x4f
[<ffffffff8145250f>] acpi_get_data_full+0x3a/0x8e
[<ffffffff81435b30>] acpi_bus_get_device+0x23/0x40
[<ffffffff8145d839>] acpi_cpu_soft_notify+0x50/0xe6
[<ffffffff810e1ddc>] notifier_call_chain+0x4c/0x70
[<ffffffff810e1eee>] __raw_notifier_call_chain+0xe/0x10
[<ffffffff810bc993>] cpu_notify+0x23/0x50
[<ffffffff810bcb98>] _cpu_up+0x168/0x180
[<ffffffff810bcc5c>] _cpu_up_with_trace+0x2c/0xe0
[<ffffffff810bd050>] ? disable_nonboot_cpus+0x1c0/0x1c0
[<ffffffff810bd06f>] async_enable_nonboot_cpus+0x1f/0x70
[<ffffffff810dda02>] kthread+0xd2/0xf0
[<ffffffff810dd930>] ? insert_kthread_work+0x40/0x40
[<ffffffff817a4dfc>] ret_from_fork+0x7c/0xb0
To avoid such deadlocks, modify acpi_os_map_cleanup() to use call_rcu()
to schedule acpi_os_async_umap() asynchronously to umap memory regions
that aren't used any more. The umap operation can't be done in the
call_rcu()'s callback directly because the callback will be called in the
soft irq context and acpi_unmap() holds mutex lock inside.
Signed-off-by: Lan Tianyu <tianyu.lan@...el.com>
[rjw: Subject and changelog.]
Cc: All applicable <stable@...r.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
Signed-off-by: Lan Tianyu <tianyu.lan@...el.com>
---
drivers/acpi/osl.c | 24 +++++++++++++++++++-----
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 3abe9b2..9baef71 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -40,6 +40,7 @@
#include <linux/nmi.h>
#include <linux/acpi.h>
#include <linux/efi.h>
+#include <linux/async.h>
#include <linux/ioport.h>
#include <linux/list.h>
#include <linux/jiffies.h>
@@ -94,6 +95,7 @@ struct acpi_ioremap {
acpi_physical_address phys;
acpi_size size;
unsigned long refcount;
+ struct rcu_head rcu;
};
static LIST_HEAD(acpi_ioremaps);
@@ -423,13 +425,25 @@ static void acpi_os_drop_map_ref(struct acpi_ioremap *map)
list_del_rcu(&map->list);
}
+static void acpi_os_async_umap(void *data, async_cookie_t cookie)
+{
+ struct acpi_ioremap *map = data;
+
+ acpi_unmap(map->phys, map->virt);
+ kfree(map);
+}
+
+static void acpi_os_map_reclaim(struct rcu_head *rcu)
+{
+ struct acpi_ioremap *map = container_of(rcu, struct acpi_ioremap, rcu);
+
+ async_schedule(acpi_os_async_umap, map);
+}
+
static void acpi_os_map_cleanup(struct acpi_ioremap *map)
{
- if (!map->refcount) {
- synchronize_rcu();
- acpi_unmap(map->phys, map->virt);
- kfree(map);
- }
+ if (!map->refcount)
+ call_rcu(&map->rcu, acpi_os_map_reclaim);
}
void __ref acpi_os_unmap_iomem(void __iomem *virt, acpi_size size)
--
1.8.4.rc0.1.g8f6a3e5.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists