Received: by 10.223.176.5 with SMTP id f5csp192280wra; Tue, 6 Feb 2018 20:17:11 -0800 (PST) X-Google-Smtp-Source: AH8x226aMuqR6ETEJ7V+GH9GGmX+fbkYtqPFEtkjozYdRmyoc5nqB0ht3v3vfh9XGAxpdjZ6ReZ0 X-Received: by 2002:a17:902:8691:: with SMTP id g17-v6mr4693905plo.446.1517977030971; Tue, 06 Feb 2018 20:17:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517977030; cv=none; d=google.com; s=arc-20160816; b=rl3Q/Z75UOaf1XeKFlQibVdjYgv0TsPVJnrRXxYkc5Yr4w0MueVa8M4UHwhkHxMUeh T8qaYfk5zyxu1iiz3riKrRd71CdkPFr1FffK4TiGcFm79SpJxVSW6IvGfc4fLn4EOcZd 0j8Omp12LTANgQZuJshWkVCjwjObNXIHwWma3eMQT9lfQGPlIHmlZBwYfDAzENre2xa+ VUcmNpeWHx3vKexi+xgOzOvsrgW/TnK7UiBHLJi+qJn4t9S4lIfE1upeeOExo001jODv o9eR0C844sqHsu8TPJbL8QXz8vDTNchF4Ijq80ZAa8jHDjShJYogmzTvxWZdhpD3Y0Om Fglg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dmarc-filter:arc-authentication-results; bh=LUk/wZSVKM/ev055PYuZumLAKLz7ZAEq8VHchY1RqnY=; b=ygnXB393laYDe+cVSCylLBSNhHwoi4IvGKQ+er58SHowj9PoFcO8hpmDC0nM9lDExF VRdyzW9knG1A3CrxZy7YkBQ2Hs1tY830yOi6s6fFUVmA6RfmvyIGf5OSjp8b8fUF4mdf MVN8hN80UU06sxtkya9sDrKXVGIodU532tjubjWC8z1+uBecjgI/4xer5l6WqZ7w6u1M VDLJTLGC2NQkUGP8w3vlg2mS1TMKY/C8G1sev3RfbD/zyJS51kAZh8QXbxRa3H9r/aTU ktv7MUdOH60wygPwh6UNeSW3qRHK7LhM5KJt3tYLEYFgKSlLX6uu/U6R6hx88ze+l9y3 qNJA== ARC-Authentication-Results: i=1; mx.google.com; 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 r4si406469pgt.200.2018.02.06.20.16.56; Tue, 06 Feb 2018 20:17:10 -0800 (PST) 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; 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 S1753430AbeBGEPm (ORCPT + 99 others); Tue, 6 Feb 2018 23:15:42 -0500 Received: from mail.kernel.org ([198.145.29.99]:45792 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753359AbeBGEPj (ORCPT ); Tue, 6 Feb 2018 23:15:39 -0500 Received: from vmware.local.home (cpe-172-100-180-131.stny.res.rr.com [172.100.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E25F82075D; Wed, 7 Feb 2018 04:15:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E25F82075D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Tue, 6 Feb 2018 23:15:35 -0500 From: Steven Rostedt To: "tip-bot for Steven Rostedt (VMware)" Cc: torvalds@linux-foundation.org, akpm@linux-foundation.org, hpa@zytor.com, rostedt@goodmis.org, peterz@infradead.org, mingo@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, efault@gmx.de, pkondeti@codeaurora.org, linux-tip-commits@vger.kernel.org, stable@vger.kernel.org Subject: Re: [tip:sched/urgent] sched/rt: Up the root domain ref count when passing it around via IPIs Message-ID: <20180206231535.626c402a@vmware.local.home> In-Reply-To: References: X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I see this was just applied to Linus's tree. This too probably should be tagged for stable as well. -- Steve On Tue, 6 Feb 2018 03:54:42 -0800 "tip-bot for Steven Rostedt (VMware)" wrote: > Commit-ID: 364f56653708ba8bcdefd4f0da2a42904baa8eeb > Gitweb: https://git.kernel.org/tip/364f56653708ba8bcdefd4f0da2a42904baa8eeb > Author: Steven Rostedt (VMware) > AuthorDate: Tue, 23 Jan 2018 20:45:38 -0500 > Committer: Ingo Molnar > CommitDate: Tue, 6 Feb 2018 10:20:33 +0100 > > sched/rt: Up the root domain ref count when passing it around via IPIs > > When issuing an IPI RT push, where an IPI is sent to each CPU that has more > than one RT task scheduled on it, it references the root domain's rto_mask, > that contains all the CPUs within the root domain that has more than one RT > task in the runable state. The problem is, after the IPIs are initiated, the > rq->lock is released. This means that the root domain that is associated to > the run queue could be freed while the IPIs are going around. > > Add a sched_get_rd() and a sched_put_rd() that will increment and decrement > the root domain's ref count respectively. This way when initiating the IPIs, > the scheduler will up the root domain's ref count before releasing the > rq->lock, ensuring that the root domain does not go away until the IPI round > is complete. > > Reported-by: Pavan Kondeti > Signed-off-by: Steven Rostedt (VMware) > Signed-off-by: Peter Zijlstra (Intel) > Cc: Andrew Morton > Cc: Linus Torvalds > Cc: Mike Galbraith > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Fixes: 4bdced5c9a292 ("sched/rt: Simplify the IPI based RT balancing logic") > Link: http://lkml.kernel.org/r/CAEU1=PkiHO35Dzna8EQqNSKW1fr1y1zRQ5y66X117MG06sQtNA@mail.gmail.com > Signed-off-by: Ingo Molnar > --- > kernel/sched/rt.c | 9 +++++++-- > kernel/sched/sched.h | 2 ++ > kernel/sched/topology.c | 13 +++++++++++++ > 3 files changed, 22 insertions(+), 2 deletions(-) > > diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c > index 2fb627d..89a086e 100644 > --- a/kernel/sched/rt.c > +++ b/kernel/sched/rt.c > @@ -1990,8 +1990,11 @@ static void tell_cpu_to_push(struct rq *rq) > > rto_start_unlock(&rq->rd->rto_loop_start); > > - if (cpu >= 0) > + if (cpu >= 0) { > + /* Make sure the rd does not get freed while pushing */ > + sched_get_rd(rq->rd); > irq_work_queue_on(&rq->rd->rto_push_work, cpu); > + } > } > > /* Called from hardirq context */ > @@ -2021,8 +2024,10 @@ void rto_push_irq_work_func(struct irq_work *work) > > raw_spin_unlock(&rd->rto_lock); > > - if (cpu < 0) > + if (cpu < 0) { > + sched_put_rd(rd); > return; > + } > > /* Try the next RT overloaded CPU */ > irq_work_queue_on(&rd->rto_push_work, cpu); > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h > index 2e95505..fb5fc45 100644 > --- a/kernel/sched/sched.h > +++ b/kernel/sched/sched.h > @@ -691,6 +691,8 @@ extern struct mutex sched_domains_mutex; > extern void init_defrootdomain(void); > extern int sched_init_domains(const struct cpumask *cpu_map); > extern void rq_attach_root(struct rq *rq, struct root_domain *rd); > +extern void sched_get_rd(struct root_domain *rd); > +extern void sched_put_rd(struct root_domain *rd); > > #ifdef HAVE_RT_PUSH_IPI > extern void rto_push_irq_work_func(struct irq_work *work); > diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c > index 034cbed..519b024 100644 > --- a/kernel/sched/topology.c > +++ b/kernel/sched/topology.c > @@ -259,6 +259,19 @@ void rq_attach_root(struct rq *rq, struct root_domain *rd) > call_rcu_sched(&old_rd->rcu, free_rootdomain); > } > > +void sched_get_rd(struct root_domain *rd) > +{ > + atomic_inc(&rd->refcount); > +} > + > +void sched_put_rd(struct root_domain *rd) > +{ > + if (!atomic_dec_and_test(&rd->refcount)) > + return; > + > + call_rcu_sched(&rd->rcu, free_rootdomain); > +} > + > static int init_rootdomain(struct root_domain *rd) > { > if (!zalloc_cpumask_var(&rd->span, GFP_KERNEL))