Received: by 10.223.176.5 with SMTP id f5csp191242wra; Tue, 6 Feb 2018 20:15:40 -0800 (PST) X-Google-Smtp-Source: AH8x227aP4wxFnMnuvXQenwi/c3eITYnzKJjPkruYfpMJIxQ5VkiZOmd5FeYKjeIjRotu9LzrdKe X-Received: by 2002:a17:902:8d85:: with SMTP id v5-v6mr4618292plo.37.1517976940303; Tue, 06 Feb 2018 20:15:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517976940; cv=none; d=google.com; s=arc-20160816; b=T3LDyrUxux8ILtUJBlSNXG/EOLwKtP/DBiyQT47MCchGZ8S5bVKUe9/ksE2ECG5uaP yC4dbPAvb8pRuEgMPHSQGbx6y1qqqmC7I47s2jfzq0hbQ2DZznuP3Ji2lQAFKVAWO/LY rgEBqbCYm0+LZqUft1jMxPi8SEYWmLS8mnezTLcB0pdzDLLR/f3VuK83B9FF+NSgxhx+ J8yJiZMPA9FwRT+4Yx9TDZhPRatW2BddZr3gyKekG2f/oZx4bTyJSqdrnABZNe527SrQ Z2QyynTSryx0ZaebJT9uAPShRZSir0KN2MCWmPN/0fXrpszJ9UmkoBK6cSv+iHBJtcdn 2AIw== 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=cIOQFlhJ4Dmm0lA3yRuGIRuFFqTENNdxpd4KwZStdrc=; b=HXzY+jdJTTXG4vDhf84Y4rpffb4Ey9yau3hmeQCIFvlrPGVNwe4P8nG3iEGVGmOBic lG7KMmUXCFGuTYb5Qf71UMCgDLA73/Wz5z1aV1ENMlp9cvF0dr9UGIXYllK2zR2bmbZT fTwXJoTDhz2VFiqf0aLvtgkiPD4QJK0nvVihuunF1UegRsbdH2+KKwPu6hY5MQa8FUYq NO7/3CRTCVOsOQA/bpTSx/I8c/tzVpXTVOhNC9o1JbeK3T5ppUYbNgrMpPjbwkzLsW33 sVkKsKBhv8FFsK0GDAle59pLWj30JlIaLqG32iFFzvJ2Vy2E2OAmnwDN7j3NXbCDSwAN pMew== 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 n6-v6si461950plp.562.2018.02.06.20.15.26; Tue, 06 Feb 2018 20:15:40 -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 S1753398AbeBGEOp (ORCPT + 99 others); Tue, 6 Feb 2018 23:14:45 -0500 Received: from mail.kernel.org ([198.145.29.99]:45354 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752564AbeBGEOo (ORCPT ); Tue, 6 Feb 2018 23:14:44 -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 0E7352075D; Wed, 7 Feb 2018 04:14:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0E7352075D 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:14:40 -0500 From: Steven Rostedt To: "tip-bot for Steven Rostedt (VMware)" Cc: pkondeti@codeaurora.org, hpa@zytor.com, linux-kernel@vger.kernel.org, rostedt@goodmis.org, efault@gmx.de, peterz@infradead.org, akpm@linux-foundation.org, torvalds@linux-foundation.org, mingo@kernel.org, tglx@linutronix.de, linux-tip-commits@vger.kernel.org, stable@vger.kernel.org Subject: Re: [tip:sched/urgent] sched/rt: Use container_of() to get root domain in rto_push_irq_work_func() Message-ID: <20180206231440.4bc7f636@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. It probably should be tagged for stable as well. -- Steve On Tue, 6 Feb 2018 03:54:16 -0800 "tip-bot for Steven Rostedt (VMware)" wrote: > Commit-ID: ad0f1d9d65938aec72a698116cd73a980916895e > Gitweb: https://git.kernel.org/tip/ad0f1d9d65938aec72a698116cd73a980916895e > Author: Steven Rostedt (VMware) > AuthorDate: Tue, 23 Jan 2018 20:45:37 -0500 > Committer: Ingo Molnar > CommitDate: Tue, 6 Feb 2018 10:20:33 +0100 > > sched/rt: Use container_of() to get root domain in rto_push_irq_work_func() > > When the rto_push_irq_work_func() is called, it looks at the RT overloaded > bitmask in the root domain via the runqueue (rq->rd). The problem is that > during CPU up and down, nothing here stops rq->rd from changing between > taking the rq->rd->rto_lock and releasing it. That means the lock that is > released is not the same lock that was taken. > > Instead of using this_rq()->rd to get the root domain, as the irq work is > part of the root domain, we can simply get the root domain from the irq work > that is passed to the routine: > > container_of(work, struct root_domain, rto_push_work) > > This keeps the root domain consistent. > > 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 | 15 ++++++++------- > 1 file changed, 8 insertions(+), 7 deletions(-) > > diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c > index 862a513..2fb627d 100644 > --- a/kernel/sched/rt.c > +++ b/kernel/sched/rt.c > @@ -1907,9 +1907,8 @@ static void push_rt_tasks(struct rq *rq) > * the rt_loop_next will cause the iterator to perform another scan. > * > */ > -static int rto_next_cpu(struct rq *rq) > +static int rto_next_cpu(struct root_domain *rd) > { > - struct root_domain *rd = rq->rd; > int next; > int cpu; > > @@ -1985,7 +1984,7 @@ static void tell_cpu_to_push(struct rq *rq) > * Otherwise it is finishing up and an ipi needs to be sent. > */ > if (rq->rd->rto_cpu < 0) > - cpu = rto_next_cpu(rq); > + cpu = rto_next_cpu(rq->rd); > > raw_spin_unlock(&rq->rd->rto_lock); > > @@ -1998,6 +1997,8 @@ static void tell_cpu_to_push(struct rq *rq) > /* Called from hardirq context */ > void rto_push_irq_work_func(struct irq_work *work) > { > + struct root_domain *rd = > + container_of(work, struct root_domain, rto_push_work); > struct rq *rq; > int cpu; > > @@ -2013,18 +2014,18 @@ void rto_push_irq_work_func(struct irq_work *work) > raw_spin_unlock(&rq->lock); > } > > - raw_spin_lock(&rq->rd->rto_lock); > + raw_spin_lock(&rd->rto_lock); > > /* Pass the IPI to the next rt overloaded queue */ > - cpu = rto_next_cpu(rq); > + cpu = rto_next_cpu(rd); > > - raw_spin_unlock(&rq->rd->rto_lock); > + raw_spin_unlock(&rd->rto_lock); > > if (cpu < 0) > return; > > /* Try the next RT overloaded CPU */ > - irq_work_queue_on(&rq->rd->rto_push_work, cpu); > + irq_work_queue_on(&rd->rto_push_work, cpu); > } > #endif /* HAVE_RT_PUSH_IPI */ >