From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967875AbdAEEWl (ORCPT ); Wed, 4 Jan 2017 23:22:41 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:43927 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967817AbdAEEVk (ORCPT ); Wed, 4 Jan 2017 23:21:40 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Andrei Vagin Cc: containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org References: <1483586894-3521-1-git-send-email-avagin@openvz.org> <8760lu9ngc.fsf@xmission.com> Date: Thu, 05 Jan 2017 17:17:47 +1300 In-Reply-To: <8760lu9ngc.fsf@xmission.com> (Eric W. Biederman's message of "Thu, 05 Jan 2017 16:48:19 +1300") Message-ID: <87vatu87is.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1cOzYY-0000Q5-4N;;;mid=<87vatu87is.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=101.100.131.98;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/o5dwsO6n4sa1X7uXm1prqLeVq5UwONAQ= X-SA-Exim-Connect-IP: 101.100.131.98 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Andrei Vagin X-Spam-Relay-Country: X-Spam-Timing: total 239 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 3.3 (1.4%), b_tie_ro: 2.3 (1.0%), parse: 0.77 (0.3%), extract_message_metadata: 15 (6.3%), get_uri_detail_list: 1.93 (0.8%), tests_pri_-1000: 8 (3.3%), tests_pri_-950: 1.10 (0.5%), tests_pri_-900: 1.02 (0.4%), tests_pri_-400: 22 (9.3%), check_bayes: 21 (8.9%), b_tokenize: 7 (2.9%), b_tok_get_all: 7 (2.8%), b_comp_prob: 2.1 (0.9%), b_tok_touch_all: 3.0 (1.3%), b_finish: 0.65 (0.3%), tests_pri_0: 180 (75.4%), check_dkim_signature: 0.48 (0.2%), check_dkim_adsp: 2.5 (1.1%), tests_pri_500: 5.0 (2.1%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] pid: fix lockdep deadlock warning due to ucount_lock X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ebiederm@xmission.com (Eric W. Biederman) writes: > Andrei Vagin 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: [] __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); >> >> 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. And now I see might_lock I can just add that into put_ucounts to try and keep this kind of issue from hiding for a full development cycle. So I will take your patch as is. Thank you, Eric > >> Cc: "Eric W. Biederman" >> Signed-off-by: Andrei Vagin >> --- >> 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); >> }