Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1618732ybb; Thu, 2 Apr 2020 04:24:25 -0700 (PDT) X-Google-Smtp-Source: APiQypKDJVMgwDtqKCOjvLBYx/IcNmwok7GG4R22Pcm0N/uNkMJJDl5xoKAVub/iwpqreCEhAuP0 X-Received: by 2002:aca:6042:: with SMTP id u63mr1839486oib.179.1585826665191; Thu, 02 Apr 2020 04:24:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585826665; cv=none; d=google.com; s=arc-20160816; b=KL+iNf6EWnyXz5NEER47UAIyBgxsZi4QiZxKxeSaIVZCijul3icG6Vhjpw47/Xf7Xn AYkSpnVApo6yK9zaqV9kk4QqkwSxW/tSDIHwDATYKpNl7D08bAbkMKTrA4W/V2nTGjjb 16K+K/+rd+d3bd+dpZ/8kzoj5MCnhzj8p1jlUcIdTXpvm9HPW9Qm68q9By2XRQ4cJvJc 7tz+Bmy8FPiTzS4WS1aqF+WITr8ycKJSuxAB+bmxrjHT2uoQWwawo4TfyEAe9KddmBeL AAS9fSLIyxy/tfMCxtYruThKc2Odnti1hpOYFbvz4Bg2KWZU0TKbabjQVAZWBHatU+2B RtaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=nPCDzOm6Xhv2kcKHvzpOL8IsDDOXYAf3749RJi90Tcs=; b=t4dETMJ6B2M6Cd0w9HnJgeXXat+wKwj2nfwdbNpqoXIMOacnVftFPVsyxSDLq+KNEJ CiA1o8cGku3nstuNd1t4M+c+Z+pSG4UtTeptLar/UbLUQY+mCDYcFzB4G2iV5LxFjzoM Dcd2WBr76KtqoTNj+dV5XC84SsOcZfkZE/Vx8M2OACRJxsc037Q1El3O+BsQWMYiJ2dF 3jkGpKpGDkJ48bwqk63HmlMlKdVrFVHAYG7IcfYV5LT9AGfiHTZcVjXfe1ArO2IeRVMc b6+kFqNZzxKXe0Hkoi8iwrlhrm8eFXV2jOkCMZjF2YpMlQRX4boQkpj7h7w/70YqkzN8 5Byg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ellerman.id.au header.s=201909 header.b=WBA8Q4J9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n5si2272812oof.46.2020.04.02.04.24.12; Thu, 02 Apr 2020 04:24:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ellerman.id.au header.s=201909 header.b=WBA8Q4J9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388077AbgDBLX6 (ORCPT + 99 others); Thu, 2 Apr 2020 07:23:58 -0400 Received: from bilbo.ozlabs.org ([203.11.71.1]:36361 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388039AbgDBLX6 (ORCPT ); Thu, 2 Apr 2020 07:23:58 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 48tLKz3MYhz9sQt; Thu, 2 Apr 2020 22:23:51 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ellerman.id.au; s=201909; t=1585826634; bh=pbSAXegT+8Z7l+avNPLwehmYnEsWWDO1v7MhVYfnlXQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=WBA8Q4J9sICs9xdSJobj+NAfU8iWBq+SIuyZsPoatm6SJyynjd/gDpSp8Q2IRLDAj qZ+iNATA+K/H1WTtmn68sbjnFno/g4Beb5PLSEi6h3QlGXkW4iCmQUeCd06yzlsh9N rY3ckrUC4nYLEOlJn0d4JZnmg7grBQmkzFyOPX+Rk0xFHFogaa/vsPtpcTkLYVpMag CYvbnUYFJF0159LbLkXs5vfYv1NvrRX3oW9uSbWq0R2Goc3QCmQnGgowk5kgCnPb85 /WRTeLt/QnmTptocrCOg0qQKSatI6wCxQ5+7e7dI2hu95e/8NQ0I8dCz/tAwQOX063 +CCfaQAvD9tjg== From: Michael Ellerman To: Qian Cai , peterz@infradead.org, mingo@redhat.com Cc: juri.lelli@redhat.com, dietmar.eggemann@arm.com, vincent.guittot@linaro.org, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, paulmck@kernel.org, tglx@linutronix.de, James.Bottomley@HansenPartnership.com, deller@gmx.de, linuxppc-dev@lists.ozlabs.org, linux-parisc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Qian Cai , Nicholas Piggin Subject: Re: [PATCH v2] sched/core: fix illegal RCU from offline CPUs In-Reply-To: <20200401214033.8448-1-cai@lca.pw> References: <20200401214033.8448-1-cai@lca.pw> Date: Thu, 02 Apr 2020 22:24:00 +1100 Message-ID: <87369mt9kf.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Qian Cai writes: > From: Peter Zijlstra > > In the CPU-offline process, it calls mmdrop() after idle entry and the > subsequent call to cpuhp_report_idle_dead(). Once execution passes the > call to rcu_report_dead(), RCU is ignoring the CPU, which results in > lockdep complaining when mmdrop() uses RCU from either memcg or > debugobjects below. > > Fix it by cleaning up the active_mm state from BP instead. Every arch > which has CONFIG_HOTPLUG_CPU should have already called idle_task_exit() > from AP. The only exception is parisc because it switches them to > &init_mm unconditionally (see smp_boot_one_cpu() and smp_cpu_init()), > but the patch will still work there because it calls mmgrab(&init_mm) in > smp_cpu_init() and then should call mmdrop(&init_mm) in finish_cpu(). Thanks for debugging this. How did you hit it in the first place? A link to the original thread would have helped me: https://lore.kernel.org/lkml/20200113190331.12788-1-cai@lca.pw/ > WARNING: suspicious RCU usage > ----------------------------- > kernel/workqueue.c:710 RCU or wq_pool_mutex should be held! > > other info that might help us debug this: > > RCU used illegally from offline CPU! > Call Trace: > dump_stack+0xf4/0x164 (unreliable) > lockdep_rcu_suspicious+0x140/0x164 > get_work_pool+0x110/0x150 > __queue_work+0x1bc/0xca0 > queue_work_on+0x114/0x120 > css_release+0x9c/0xc0 > percpu_ref_put_many+0x204/0x230 > free_pcp_prepare+0x264/0x570 > free_unref_page+0x38/0xf0 > __mmdrop+0x21c/0x2c0 > idle_task_exit+0x170/0x1b0 > pnv_smp_cpu_kill_self+0x38/0x2e0 > cpu_die+0x48/0x64 > arch_cpu_idle_dead+0x30/0x50 > do_idle+0x2f4/0x470 > cpu_startup_entry+0x38/0x40 > start_secondary+0x7a8/0xa80 > start_secondary_resume+0x10/0x14 Do we know when this started happening? ie. can we determine a Fixes tag? > > Signed-off-by: Qian Cai > --- > arch/powerpc/platforms/powernv/smp.c | 1 - > include/linux/sched/mm.h | 2 ++ > kernel/cpu.c | 18 +++++++++++++++++- > kernel/sched/core.c | 5 +++-- > 4 files changed, 22 insertions(+), 4 deletions(-) > > diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/powernv/smp.c > index 13e251699346..b2ba3e95bda7 100644 > --- a/arch/powerpc/platforms/powernv/smp.c > +++ b/arch/powerpc/platforms/powernv/smp.c > @@ -167,7 +167,6 @@ static void pnv_smp_cpu_kill_self(void) > /* Standard hot unplug procedure */ > > idle_task_exit(); > - current->active_mm = NULL; /* for sanity */ If I'm reading it right, we'll now be running with active_mm == init_mm in the offline loop. I guess that's fine, I can't think of any reason it would matter, and it seems like we were NULL'ing it out just for paranoia's sake not because of any actual problem. Acked-by: Michael Ellerman (powerpc) cheers > diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h > index c49257a3b510..a132d875d351 100644 > --- a/include/linux/sched/mm.h > +++ b/include/linux/sched/mm.h > @@ -49,6 +49,8 @@ static inline void mmdrop(struct mm_struct *mm) > __mmdrop(mm); > } > > +void mmdrop(struct mm_struct *mm); > + > /* > * This has to be called after a get_task_mm()/mmget_not_zero() > * followed by taking the mmap_sem for writing before modifying the > diff --git a/kernel/cpu.c b/kernel/cpu.c > index 2371292f30b0..244d30544377 100644 > --- a/kernel/cpu.c > +++ b/kernel/cpu.c > @@ -3,6 +3,7 @@ > * > * This code is licenced under the GPL. > */ > +#include > #include > #include > #include > @@ -564,6 +565,21 @@ static int bringup_cpu(unsigned int cpu) > return bringup_wait_for_ap(cpu); > } > > +static int finish_cpu(unsigned int cpu) > +{ > + struct task_struct *idle = idle_thread_get(cpu); > + struct mm_struct *mm = idle->active_mm; > + > + /* > + * idle_task_exit() will have switched to &init_mm, now > + * clean up any remaining active_mm state. > + */ > + if (mm != &init_mm) > + idle->active_mm = &init_mm; > + mmdrop(mm); > + return 0; > +} > + > /* > * Hotplug state machine related functions > */ > @@ -1549,7 +1565,7 @@ static struct cpuhp_step cpuhp_hp_states[] = { > [CPUHP_BRINGUP_CPU] = { > .name = "cpu:bringup", > .startup.single = bringup_cpu, > - .teardown.single = NULL, > + .teardown.single = finish_cpu, > .cant_stop = true, > }, > /* Final state before CPU kills itself */ > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index a2694ba82874..8787958339d5 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -6200,13 +6200,14 @@ void idle_task_exit(void) > struct mm_struct *mm = current->active_mm; > > BUG_ON(cpu_online(smp_processor_id())); > + BUG_ON(current != this_rq()->idle); > > if (mm != &init_mm) { > switch_mm(mm, &init_mm, current); > - current->active_mm = &init_mm; > finish_arch_post_lock_switch(); > } > - mmdrop(mm); > + > + /* finish_cpu(), as ran on the BP, will clean up the active_mm state */ > } > > /* > -- > 2.21.0 (Apple Git-122.2)