From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Andrei Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] pid: fix lockdep deadlock warning due to ucount_lock
Date: Thu, 05 Jan 2017 16:48:19 +1300 [thread overview]
Message-ID: <8760lu9ngc.fsf@xmission.com> (raw)
In-Reply-To: <1483586894-3521-1-git-send-email-avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org> (Andrei Vagin's message of "Wed, 4 Jan 2017 19:28:14 -0800")
Andrei Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org> writes:
> =========================================================
> [ INFO: possible irq lock inversion dependency detected ]
> 4.10.0-rc2-00024-g4aecec9-dirty #118 Tainted: G W
> ---------------------------------------------------------
> swapper/1/0 just changed the state of lock:
> (&(&sighand->siglock)->rlock){-.....}, at: [<ffffffffbd0a1bc6>] __lock_task_sighand+0xb6/0x2c0
> but this lock took another, HARDIRQ-unsafe lock in the past:
> (ucounts_lock){+.+...}
> and interrupts could create inverse lock ordering between them.
> other info that might help us debug this:
> Chain exists of: &(&sighand->siglock)->rlock --> &(&tty->ctrl_lock)->rlock --> ucounts_lock
> Possible interrupt unsafe locking scenario:
> CPU0 CPU1
> ---- ----
> lock(ucounts_lock);
> local_irq_disable();
> lock(&(&sighand->siglock)->rlock);
> lock(&(&tty->ctrl_lock)->rlock);
> <Interrupt>
> lock(&(&sighand->siglock)->rlock);
>
> *** DEADLOCK ***
>
> This patch removes a dependency between rlock and ucount_lock.
It would have clearer if you had included the call chain where
destroy_pid_namespaces is called with siglock held.
Do you see any good reason not to just change put_ucounts to
use spin_lock_irqsave? Otherwise this looks like a class of bug that
will creep in again. As having the last user of ucounts exit and call
put_ucount in the right conditions looks like something that will
be hard to trigger in with lockdep.
Eric
> Cc: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Andrei Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
> ---
> kernel/pid_namespace.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
> index df9e8e9..eef2ce9 100644
> --- a/kernel/pid_namespace.c
> +++ b/kernel/pid_namespace.c
> @@ -151,8 +151,12 @@ static struct pid_namespace *create_pid_namespace(struct user_namespace *user_ns
>
> static void delayed_free_pidns(struct rcu_head *p)
> {
> - kmem_cache_free(pid_ns_cachep,
> - container_of(p, struct pid_namespace, rcu));
> + struct pid_namespace *ns = container_of(p, struct pid_namespace, rcu);
> +
> + dec_pid_namespaces(ns->ucounts);
> + put_user_ns(ns->user_ns);
> +
> + kmem_cache_free(pid_ns_cachep, ns);
> }
>
> static void destroy_pid_namespace(struct pid_namespace *ns)
> @@ -162,8 +166,6 @@ static void destroy_pid_namespace(struct pid_namespace *ns)
> ns_free_inum(&ns->ns);
> for (i = 0; i < PIDMAP_ENTRIES; i++)
> kfree(ns->pidmap[i].page);
> - dec_pid_namespaces(ns->ucounts);
> - put_user_ns(ns->user_ns);
> call_rcu(&ns->rcu, delayed_free_pidns);
> }
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrei Vagin <avagin@openvz.org>
Cc: containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] pid: fix lockdep deadlock warning due to ucount_lock
Date: Thu, 05 Jan 2017 16:48:19 +1300 [thread overview]
Message-ID: <8760lu9ngc.fsf@xmission.com> (raw)
In-Reply-To: <1483586894-3521-1-git-send-email-avagin@openvz.org> (Andrei Vagin's message of "Wed, 4 Jan 2017 19:28:14 -0800")
Andrei Vagin <avagin@openvz.org> writes:
> =========================================================
> [ INFO: possible irq lock inversion dependency detected ]
> 4.10.0-rc2-00024-g4aecec9-dirty #118 Tainted: G W
> ---------------------------------------------------------
> swapper/1/0 just changed the state of lock:
> (&(&sighand->siglock)->rlock){-.....}, at: [<ffffffffbd0a1bc6>] __lock_task_sighand+0xb6/0x2c0
> but this lock took another, HARDIRQ-unsafe lock in the past:
> (ucounts_lock){+.+...}
> and interrupts could create inverse lock ordering between them.
> other info that might help us debug this:
> Chain exists of: &(&sighand->siglock)->rlock --> &(&tty->ctrl_lock)->rlock --> ucounts_lock
> Possible interrupt unsafe locking scenario:
> CPU0 CPU1
> ---- ----
> lock(ucounts_lock);
> local_irq_disable();
> lock(&(&sighand->siglock)->rlock);
> lock(&(&tty->ctrl_lock)->rlock);
> <Interrupt>
> lock(&(&sighand->siglock)->rlock);
>
> *** DEADLOCK ***
>
> This patch removes a dependency between rlock and ucount_lock.
It would have clearer if you had included the call chain where
destroy_pid_namespaces is called with siglock held.
Do you see any good reason not to just change put_ucounts to
use spin_lock_irqsave? Otherwise this looks like a class of bug that
will creep in again. As having the last user of ucounts exit and call
put_ucount in the right conditions looks like something that will
be hard to trigger in with lockdep.
Eric
> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> Signed-off-by: Andrei Vagin <avagin@openvz.org>
> ---
> kernel/pid_namespace.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/pid_namespace.c b/kernel/pid_namespace.c
> index df9e8e9..eef2ce9 100644
> --- a/kernel/pid_namespace.c
> +++ b/kernel/pid_namespace.c
> @@ -151,8 +151,12 @@ static struct pid_namespace *create_pid_namespace(struct user_namespace *user_ns
>
> static void delayed_free_pidns(struct rcu_head *p)
> {
> - kmem_cache_free(pid_ns_cachep,
> - container_of(p, struct pid_namespace, rcu));
> + struct pid_namespace *ns = container_of(p, struct pid_namespace, rcu);
> +
> + dec_pid_namespaces(ns->ucounts);
> + put_user_ns(ns->user_ns);
> +
> + kmem_cache_free(pid_ns_cachep, ns);
> }
>
> static void destroy_pid_namespace(struct pid_namespace *ns)
> @@ -162,8 +166,6 @@ static void destroy_pid_namespace(struct pid_namespace *ns)
> ns_free_inum(&ns->ns);
> for (i = 0; i < PIDMAP_ENTRIES; i++)
> kfree(ns->pidmap[i].page);
> - dec_pid_namespaces(ns->ucounts);
> - put_user_ns(ns->user_ns);
> call_rcu(&ns->rcu, delayed_free_pidns);
> }
next prev parent reply other threads:[~2017-01-05 3:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-05 3:28 [PATCH] pid: fix lockdep deadlock warning due to ucount_lock Andrei Vagin
2017-01-05 3:28 ` Andrei Vagin
[not found] ` <1483586894-3521-1-git-send-email-avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2017-01-05 3:48 ` Eric W. Biederman [this message]
2017-01-05 3:48 ` Eric W. Biederman
[not found] ` <8760lu9ngc.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-01-05 4:17 ` Eric W. Biederman
2017-01-05 4:17 ` Eric W. Biederman
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=8760lu9ngc.fsf@xmission.com \
--to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
--cc=avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.