Waiman Long
ddc204b517
copy_process(): Move fd_install() out of sighand->siglock critical section
I was made aware of the following lockdep splat:
[ 2516.308763] =====================================================
[ 2516.309085] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
[ 2516.309433] 5.14.0-51.el9.aarch64+debug #1 Not tainted
[ 2516.309703] -----------------------------------------------------
[ 2516.310149] stress-ng/153663 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 2516.310512] ffff0000e422b198 (&newf->file_lock){+.+.}-{2:2}, at: fd_install+0x368/0x4f0
[ 2516.310944]
and this task is already holding:
[ 2516.311248] ffff0000c08140d8 (&sighand->siglock){-.-.}-{2:2}, at: copy_process+0x1e2c/0x3e80
[ 2516.311804] which would create a new lock dependency:
[ 2516.312066] (&sighand->siglock){-.-.}-{2:2} -> (&newf->file_lock){+.+.}-{2:2}
[ 2516.312446]
but this new dependency connects a HARDIRQ-irq-safe lock:
[ 2516.312983] (&sighand->siglock){-.-.}-{2:2}
:
[ 2516.330700] Possible interrupt unsafe locking scenario:
[ 2516.331075] CPU0 CPU1
[ 2516.331328] ---- ----
[ 2516.331580] lock(&newf->file_lock);
[ 2516.331790] local_irq_disable();
[ 2516.332231] lock(&sighand->siglock);
[ 2516.332579] lock(&newf->file_lock);
[ 2516.332922] <Interrupt>
[ 2516.333069] lock(&sighand->siglock);
[ 2516.333291]
*** DEADLOCK ***
[ 2516.389845]
stack backtrace:
[ 2516.390101] CPU: 3 PID: 153663 Comm: stress-ng Kdump: loaded Not tainted 5.14.0-51.el9.aarch64+debug #1
[ 2516.390756] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 2516.391155] Call trace:
[ 2516.391302] dump_backtrace+0x0/0x3e0
[ 2516.391518] show_stack+0x24/0x30
[ 2516.391717] dump_stack_lvl+0x9c/0xd8
[ 2516.391938] dump_stack+0x1c/0x38
[ 2516.392247] print_bad_irq_dependency+0x620/0x710
[ 2516.392525] check_irq_usage+0x4fc/0x86c
[ 2516.392756] check_prev_add+0x180/0x1d90
[ 2516.392988] validate_chain+0x8e0/0xee0
[ 2516.393215] __lock_acquire+0x97c/0x1e40
[ 2516.393449] lock_acquire.part.0+0x240/0x570
[ 2516.393814] lock_acquire+0x90/0xb4
[ 2516.394021] _raw_spin_lock+0xe8/0x154
[ 2516.394244] fd_install+0x368/0x4f0
[ 2516.394451] copy_process+0x1f5c/0x3e80
[ 2516.394678] kernel_clone+0x134/0x660
[ 2516.394895] __do_sys_clone3+0x130/0x1f4
[ 2516.395128] __arm64_sys_clone3+0x5c/0x7c
[ 2516.395478] invoke_syscall.constprop.0+0x78/0x1f0
[ 2516.395762] el0_svc_common.constprop.0+0x22c/0x2c4
[ 2516.396050] do_el0_svc+0xb0/0x10c
[ 2516.396252] el0_svc+0x24/0x34
[ 2516.396436] el0t_64_sync_handler+0xa4/0x12c
[ 2516.396688] el0t_64_sync+0x198/0x19c
[ 2517.491197] NET: Registered PF_ATMPVC protocol family
[ 2517.491524] NET: Registered PF_ATMSVC protocol family
[ 2591.991877] sched: RT throttling activated
One way to solve this problem is to move the fd_install() call out of
the sighand->siglock critical section.
Before commit 6fd2fe494b ("copy_process(): don't use ksys_close()
on cleanups"), the pidfd installation was done without holding both
the task_list lock and the sighand->siglock. Obviously, holding these
two locks are not really needed to protect the fd_install() call.
So move the fd_install() call down to after the releases of both locks.
Link: https://lore.kernel.org/r/20220208163912.1084752-1-longman@redhat.com
Fixes: 6fd2fe494b ("copy_process(): don't use ksys_close() on cleanups")
Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
2022-02-11 09:28:32 +01:00
..
2022-02-03 13:42:38 -08:00
2022-02-03 08:15:13 -08:00
2022-01-20 08:52:55 +02:00
2021-11-03 17:21:37 +00:00
2022-01-16 15:53:00 +02:00
2021-12-01 00:06:43 +01:00
2022-02-02 13:11:40 +01:00
2022-01-17 05:49:30 +02:00
2021-12-02 17:25:21 +09:00
2022-01-22 08:33:37 +02:00
2022-01-11 09:51:26 -08:00
2022-01-16 10:08:13 +02:00
2022-01-22 08:33:37 +02:00
2022-01-25 18:34:08 +01:00
2022-02-03 11:27:38 -08:00
2022-01-26 13:04:05 -08:00
2022-01-30 13:09:00 +02:00
2022-01-23 06:20:44 +02:00
2022-01-27 19:15:49 -05:00
2021-05-02 00:43:35 +09:00
2021-10-18 06:17:01 -06:00
2022-02-03 11:20:34 -08:00
2021-10-27 12:32:34 +02:00
2021-12-14 17:39:42 -05:00
2021-11-06 16:43:20 -07:00
2022-01-25 13:22:51 -05:00
2021-11-01 21:17:39 -07:00
2022-01-11 13:08:21 -08:00
2021-11-22 17:52:47 -05:00
2021-08-11 13:11:12 -07:00
2021-09-08 15:32:35 -07:00
2021-08-16 18:55:32 +02:00
2021-11-24 12:20:27 +01:00
2021-12-25 12:20:55 -08:00
2021-10-20 10:45:34 -05:00
2022-01-20 08:52:55 +02:00
2022-01-08 12:43:57 -06:00
2021-11-09 10:02:51 -08:00
2022-02-11 09:28:32 +01:00
2021-06-18 11:43:08 +02:00
2021-05-27 04:01:50 +09:00
2022-01-22 08:33:34 +02:00
2021-10-15 11:25:18 +02:00
2021-07-05 10:46:20 +02:00
2022-01-16 10:08:13 +02:00
2021-08-17 17:50:51 +02:00
2021-11-11 13:09:33 +01:00
2021-11-09 10:02:52 -08:00
2021-12-13 12:04:45 -06:00
2021-11-06 13:30:42 -07:00
2021-09-08 15:32:34 -07:00
2021-05-07 00:26:33 -07:00
2022-01-22 08:33:36 +02:00
2022-01-20 10:41:01 +02:00
2022-01-11 18:45:02 -08:00
2022-01-13 07:17:47 -08:00
2022-01-11 18:45:02 -08:00
2022-02-03 11:20:34 -08:00
2021-12-29 10:37:33 +01:00
2021-09-03 09:58:12 -07:00
2021-08-27 16:30:18 +08:00
2022-01-20 08:52:55 +02:00
2021-12-28 11:26:18 +01:00
2021-09-03 09:58:12 -07:00
2021-10-14 13:29:18 +02:00
2022-01-08 12:43:57 -06:00
2022-01-08 12:43:57 -06:00
2021-11-12 11:53:16 -08:00
2022-01-22 08:33:37 +02:00
2021-09-22 10:24:01 -04:00
2021-12-07 16:36:17 -08:00
2021-09-30 09:37:27 +01:00
2021-09-01 14:52:05 -07:00
2022-01-17 05:49:30 +02:00
2021-10-22 15:32:46 +02:00
2021-08-10 14:57:42 +02:00
2021-12-02 15:07:22 +01:00
2022-02-03 17:02:21 -08:00
2021-11-06 13:30:43 -07:00
2021-07-05 10:46:33 +02:00
2022-01-15 16:30:30 +02:00
2022-01-20 10:41:01 +02:00
2021-06-23 16:41:24 -06:00
2022-01-22 08:33:37 +02:00
2021-04-30 11:20:42 -07:00
2021-12-07 16:36:17 -08:00
2021-08-16 11:39:51 -04:00
2022-01-08 12:43:57 -06:00
2022-01-26 18:34:11 -06:00
2021-05-07 00:26:34 -07:00
2021-05-09 13:07:03 -07:00
2021-09-03 09:58:12 -07:00
2021-09-08 11:50:27 -07:00
2021-07-03 11:41:14 -07:00
2022-01-22 08:33:34 +02:00
2021-08-17 07:49:10 -10:00
2022-01-10 07:54:04 -10:00