public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Waiman Long <longman@redhat.com>
Cc: Christian Brauner <brauner@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>, Alexey Gladkov <legion@kernel.org>,
	David Hildenbrand <david@redhat.com>,
	Jann Horn <jannh@google.com>, Al Viro <viro@zeniv.linux.org.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] copy_process(): Move fd_install() out of sighand->siglock critical section
Date: Wed, 09 Feb 2022 16:18:46 -0600	[thread overview]
Message-ID: <87h797adkp.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <20220208163912.1084752-1-longman@redhat.com> (Waiman Long's message of "Tue, 8 Feb 2022 11:39:12 -0500")

Waiman Long <longman@redhat.com> writes:

> 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 6fd2fe494b17 ("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.
>
> Fixes: 6fd2fe494b17 ("copy_process(): don't use ksys_close() on cleanups")
> Signed-off-by: Waiman Long <longman@redhat.com>

The fd_install can not be moved earlier and it does need to be moved
outside the locks.

Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>

> ---
>  kernel/fork.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index d75a528f7b21..007af7fb47c7 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -2323,10 +2323,6 @@ static __latent_entropy struct task_struct *copy_process(
>  		goto bad_fork_cancel_cgroup;
>  	}
>  
> -	/* past the last point of failure */
> -	if (pidfile)
> -		fd_install(pidfd, pidfile);
> -
>  	init_task_pid_links(p);
>  	if (likely(p->pid)) {
>  		ptrace_init_task(p, (clone_flags & CLONE_PTRACE) || trace);
> @@ -2375,6 +2371,9 @@ static __latent_entropy struct task_struct *copy_process(
>  	syscall_tracepoint_update(p);
>  	write_unlock_irq(&tasklist_lock);
>  
> +	if (pidfile)
> +		fd_install(pidfd, pidfile);
> +
>  	proc_fork_connector(p);
>  	sched_post_fork(p, args);
>  	cgroup_post_fork(p, args);

      parent reply	other threads:[~2022-02-09 22:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-08 16:39 [PATCH] copy_process(): Move fd_install() out of sighand->siglock critical section Waiman Long
2022-02-08 18:16 ` Al Viro
2022-02-08 18:51   ` Waiman Long
2022-02-08 19:07     ` Al Viro
2022-02-08 21:59       ` Eric W. Biederman
2022-02-08 22:16         ` Al Viro
2022-02-08 22:25           ` Eric W. Biederman
2022-02-09 16:25         ` Waiman Long
2022-02-11  8:27       ` Christian Brauner
2022-02-09 22:18 ` Eric W. Biederman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h797adkp.fsf@email.froward.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=david@redhat.com \
    --cc=jannh@google.com \
    --cc=legion@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox