Jiada Wang
e73e81975f
sched/debug: Fix potential deadlock when writing to sched_features
The following lockdep report can be triggered by writing to /sys/kernel/debug/sched_features:
======================================================
WARNING: possible circular locking dependency detected
4.18.0-rc6-00152-gcd3f77d74ac3-dirty #18 Not tainted
------------------------------------------------------
sh/3358 is trying to acquire lock:
000000004ad3989d (cpu_hotplug_lock.rw_sem){++++}, at: static_key_enable+0x14/0x30
but task is already holding lock:
00000000c1b31a88 (&sb->s_type->i_mutex_key#3){+.+.}, at: sched_feat_write+0x160/0x428
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&sb->s_type->i_mutex_key#3){+.+.}:
lock_acquire+0xb8/0x148
down_write+0xac/0x140
start_creating+0x5c/0x168
debugfs_create_dir+0x18/0x220
opp_debug_register+0x8c/0x120
_add_opp_dev+0x104/0x1f8
dev_pm_opp_get_opp_table+0x174/0x340
_of_add_opp_table_v2+0x110/0x760
dev_pm_opp_of_add_table+0x5c/0x240
dev_pm_opp_of_cpumask_add_table+0x5c/0x100
cpufreq_init+0x160/0x430
cpufreq_online+0x1cc/0xe30
cpufreq_add_dev+0x78/0x198
subsys_interface_register+0x168/0x270
cpufreq_register_driver+0x1c8/0x278
dt_cpufreq_probe+0xdc/0x1b8
platform_drv_probe+0xb4/0x168
driver_probe_device+0x318/0x4b0
__device_attach_driver+0xfc/0x1f0
bus_for_each_drv+0xf8/0x180
__device_attach+0x164/0x200
device_initial_probe+0x10/0x18
bus_probe_device+0x110/0x178
device_add+0x6d8/0x908
platform_device_add+0x138/0x3d8
platform_device_register_full+0x1cc/0x1f8
cpufreq_dt_platdev_init+0x174/0x1bc
do_one_initcall+0xb8/0x310
kernel_init_freeable+0x4b8/0x56c
kernel_init+0x10/0x138
ret_from_fork+0x10/0x18
-> #2 (opp_table_lock){+.+.}:
lock_acquire+0xb8/0x148
__mutex_lock+0x104/0xf50
mutex_lock_nested+0x1c/0x28
_of_add_opp_table_v2+0xb4/0x760
dev_pm_opp_of_add_table+0x5c/0x240
dev_pm_opp_of_cpumask_add_table+0x5c/0x100
cpufreq_init+0x160/0x430
cpufreq_online+0x1cc/0xe30
cpufreq_add_dev+0x78/0x198
subsys_interface_register+0x168/0x270
cpufreq_register_driver+0x1c8/0x278
dt_cpufreq_probe+0xdc/0x1b8
platform_drv_probe+0xb4/0x168
driver_probe_device+0x318/0x4b0
__device_attach_driver+0xfc/0x1f0
bus_for_each_drv+0xf8/0x180
__device_attach+0x164/0x200
device_initial_probe+0x10/0x18
bus_probe_device+0x110/0x178
device_add+0x6d8/0x908
platform_device_add+0x138/0x3d8
platform_device_register_full+0x1cc/0x1f8
cpufreq_dt_platdev_init+0x174/0x1bc
do_one_initcall+0xb8/0x310
kernel_init_freeable+0x4b8/0x56c
kernel_init+0x10/0x138
ret_from_fork+0x10/0x18
-> #1 (subsys mutex#6){+.+.}:
lock_acquire+0xb8/0x148
__mutex_lock+0x104/0xf50
mutex_lock_nested+0x1c/0x28
subsys_interface_register+0xd8/0x270
cpufreq_register_driver+0x1c8/0x278
dt_cpufreq_probe+0xdc/0x1b8
platform_drv_probe+0xb4/0x168
driver_probe_device+0x318/0x4b0
__device_attach_driver+0xfc/0x1f0
bus_for_each_drv+0xf8/0x180
__device_attach+0x164/0x200
device_initial_probe+0x10/0x18
bus_probe_device+0x110/0x178
device_add+0x6d8/0x908
platform_device_add+0x138/0x3d8
platform_device_register_full+0x1cc/0x1f8
cpufreq_dt_platdev_init+0x174/0x1bc
do_one_initcall+0xb8/0x310
kernel_init_freeable+0x4b8/0x56c
kernel_init+0x10/0x138
ret_from_fork+0x10/0x18
-> #0 (cpu_hotplug_lock.rw_sem){++++}:
__lock_acquire+0x203c/0x21d0
lock_acquire+0xb8/0x148
cpus_read_lock+0x58/0x1c8
static_key_enable+0x14/0x30
sched_feat_write+0x314/0x428
full_proxy_write+0xa0/0x138
__vfs_write+0xd8/0x388
vfs_write+0xdc/0x318
ksys_write+0xb4/0x138
sys_write+0xc/0x18
__sys_trace_return+0x0/0x4
other info that might help us debug this:
Chain exists of:
cpu_hotplug_lock.rw_sem --> opp_table_lock --> &sb->s_type->i_mutex_key#3
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&sb->s_type->i_mutex_key#3);
lock(opp_table_lock);
lock(&sb->s_type->i_mutex_key#3);
lock(cpu_hotplug_lock.rw_sem);
*** DEADLOCK ***
2 locks held by sh/3358:
#0: 00000000a8c4b363 (sb_writers#10){.+.+}, at: vfs_write+0x238/0x318
#1: 00000000c1b31a88 (&sb->s_type->i_mutex_key#3){+.+.}, at: sched_feat_write+0x160/0x428
stack backtrace:
CPU: 5 PID: 3358 Comm: sh Not tainted 4.18.0-rc6-00152-gcd3f77d74ac3-dirty #18
Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT)
Call trace:
dump_backtrace+0x0/0x288
show_stack+0x14/0x20
dump_stack+0x13c/0x1ac
print_circular_bug.isra.10+0x270/0x438
check_prev_add.constprop.16+0x4dc/0xb98
__lock_acquire+0x203c/0x21d0
lock_acquire+0xb8/0x148
cpus_read_lock+0x58/0x1c8
static_key_enable+0x14/0x30
sched_feat_write+0x314/0x428
full_proxy_write+0xa0/0x138
__vfs_write+0xd8/0x388
vfs_write+0xdc/0x318
ksys_write+0xb4/0x138
sys_write+0xc/0x18
__sys_trace_return+0x0/0x4
This is because when loading the cpufreq_dt module we first acquire
cpu_hotplug_lock.rw_sem lock, then in cpufreq_init(), we are taking
the &sb->s_type->i_mutex_key lock.
But when writing to /sys/kernel/debug/sched_features, the
cpu_hotplug_lock.rw_sem lock depends on the &sb->s_type->i_mutex_key lock.
To fix this bug, reverse the lock acquisition order when writing to
sched_features, this way cpu_hotplug_lock.rw_sem no longer depends on
&sb->s_type->i_mutex_key.
Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Eugeniu Rosca <erosca@de.adit-jv.com>
Cc: George G. Davis <george_davis@mentor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180731121222.26195-1-jiada_wang@mentor.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-10 10:13:45 +02:00
..
2018-09-02 22:31:10 +02:00
2018-08-24 13:19:27 -07:00
2018-06-15 07:15:28 +09:00
2018-06-12 16:19:22 -07:00
2018-09-01 15:42:28 +02:00
2018-08-23 18:48:43 -07:00
2018-06-08 18:56:02 +09:00
2018-08-13 10:47:26 -07:00
2018-08-20 18:33:50 +02:00
2018-08-20 18:32:00 -07:00
2018-08-15 00:07:08 +02:00
2018-09-06 11:24:05 -04:00
2018-08-13 11:25:07 -07:00
2018-09-10 10:13:45 +02:00
2018-09-06 23:38:35 +02:00
2018-08-23 13:07:00 -07:00
2018-01-04 16:45:09 -08:00
2018-02-06 18:32:44 -08:00
2018-05-18 14:58:22 +02:00
2018-08-17 09:41:28 -07:00
2018-07-18 11:43:36 -04:00
2018-07-17 14:45:08 -04:00
2018-02-23 11:22:22 -05:00
2018-06-19 10:39:54 -04:00
2018-08-15 10:46:54 -07:00
2018-06-24 14:39:47 +02:00
2018-09-06 15:21:38 +02:00
2018-08-22 10:52:47 -07:00
2018-04-27 14:34:51 +02:00
2018-05-16 07:23:35 +02:00
2018-05-16 07:23:35 +02:00
2018-07-21 12:57:35 -05:00
2018-02-21 16:54:06 +01:00
2018-06-21 12:33:19 +02:00
2018-09-04 16:45:02 -07:00
2018-08-06 12:35:20 +02:00
2018-08-20 18:23:00 +02:00
2017-12-14 16:00:49 -08:00
2018-08-22 10:52:47 -07:00
2018-05-15 23:08:33 -07:00
2018-01-08 19:43:15 +01:00
2018-03-20 08:57:17 +01:00
2018-08-14 19:12:29 -03:00
2018-08-02 08:06:54 +09:00
2018-06-15 07:55:24 +09:00
2018-06-15 07:55:24 +09:00
2018-06-12 16:19:22 -07:00
2018-07-16 12:31:57 -07:00
2018-06-21 17:33:42 +02:00
2018-08-13 11:25:07 -07:00
2018-07-18 01:18:05 +09:00
2018-08-25 18:43:59 -07:00
2018-07-02 11:36:17 +02:00
2018-07-02 11:36:17 +02:00
2018-08-22 10:52:47 -07:00
2018-01-05 18:43:00 +11:00
2018-06-14 12:21:18 +09:00
2018-04-11 10:28:37 -07:00
2018-04-03 19:15:32 -07:00
2018-07-21 10:43:12 -05:00
2018-02-06 18:32:46 -08:00
2018-08-06 12:35:20 +02:00
2018-06-15 07:55:24 +09:00
2018-06-08 17:21:52 -07:00
2018-07-10 22:18:52 +02:00
2018-06-06 16:34:00 -07:00
2018-08-22 12:34:08 -07:00
2018-08-07 12:25:30 +02:00
2018-07-03 09:20:44 +02:00
2018-08-03 15:52:10 +02:00
2018-08-13 11:25:07 -07:00
2018-06-10 10:17:09 -07:00
2018-08-24 09:25:39 -07:00
2018-04-16 11:26:49 +02:00
2018-08-23 18:48:43 -07:00
2017-12-17 13:57:15 +01:00
2018-02-06 18:32:46 -08:00
2018-06-21 12:33:05 +02:00
2018-06-25 11:30:10 -07:00
2018-08-22 10:52:47 -07:00
2018-04-05 21:36:27 -07:00
2018-04-02 20:15:59 +02:00
2018-04-02 20:15:30 +02:00
2018-06-07 16:56:28 -04:00
2018-08-11 02:05:53 -05:00
2018-08-22 10:52:47 -07:00
2018-08-11 02:05:53 -05:00
2018-04-11 10:28:35 -07:00
2018-08-30 12:56:40 +02:00
2018-08-30 12:56:40 +02:00
2018-05-18 08:47:13 -07:00
2018-08-30 12:56:40 +02:00