Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3856753pxk; Tue, 29 Sep 2020 07:57:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxvYLddeZyzAmxxO1iBm5FemJcHedVBhsretMc7X7JUaYy8UhiICx3npWpiO0ax8FwoLMBI X-Received: by 2002:a05:6402:696:: with SMTP id f22mr3634102edy.290.1601391469730; Tue, 29 Sep 2020 07:57:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601391469; cv=none; d=google.com; s=arc-20160816; b=ILgovEaPIF9tyJHQ35OWB6HiDCUx8qwyphqhf0WYv144049L4UVZBAoq8gVzzlJyaV cXx9/cTJYP7t5OpAEFSCnJdPhoDC4v0y4KliF76Yc5KhnXfzX9jSQG7R2bUgSJ5/8dhC pWc5WrBz0fIFI1cW+7aLwvjYn+rYjPg5taY0q2Uw8mBOpeHxQAET31GpA+1stfmtMgMS 2ffi3iiy6TUH3HLkezGMGqFah9wR/uHiRQxK2YeyE0UJkvjjie1ibAGxqu68nqz/G9qJ JRZYdDRcCIguJqNX7GY32FmQ+RJHKOEJv501yqef4fOAeBUsL+k4oM3h+Z+0PTJ7CX/7 71EQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=3m/Y9+w8eu6J0Z+GB/piZkSff7QblvgfR7aHYjvbf+4=; b=vCvc/hqVQFfADRfIGrSrPdGUhxPD2NbGVIk0/GFxHCL2D8yhcaWBuBKeJQRBNq3SZj +WU9pTOtP7z/plWQW6IwdG4cxxeXBTQx1O9FE2zD6cDGpwJOomZ9ZlIimHg6m3CbEe/h 5K1gkjnx8KMKaNcWmARezFnZi2SSz9YTH3izNEU0iJtPLEtfvB53bzVn1YoZpcXnMImI tJpdu8S6xRX5fMCEIo7BlGXJ8tHGSknYPB6aY3J0yBYs53C3U6J4nGHMQfyC791w5OxZ iCUZxk+BnEEfTJmTLoLCXlMIurTwNBubpUa2W/H1wcxyEBMSzZtIDNyLQSR8JLUIi4bp o5+A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x10si2918401eju.11.2020.09.29.07.57.26; Tue, 29 Sep 2020 07:57:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731070AbgI2Oy0 (ORCPT + 99 others); Tue, 29 Sep 2020 10:54:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:51892 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728627AbgI2Oy0 (ORCPT ); Tue, 29 Sep 2020 10:54:26 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (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 45DEF20757; Tue, 29 Sep 2020 14:54:25 +0000 (UTC) Date: Tue, 29 Sep 2020 10:54:16 -0400 From: Steven Rostedt To: "Paul E. McKenney" Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , kim.phillips@amd.com Subject: Re: [PATCH] rcu,ftrace: Fix ftrace recursion Message-ID: <20200929105416.757c47f0@gandalf.local.home> In-Reply-To: <20200929144105.GU29330@paulmck-ThinkPad-P72> References: <20200929113340.GN2628@hirez.programming.kicks-ass.net> <20200929103620.06762622@gandalf.local.home> <20200929144105.GU29330@paulmck-ThinkPad-P72> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 29 Sep 2020 07:41:06 -0700 "Paul E. McKenney" wrote: > On Tue, Sep 29, 2020 at 10:36:20AM -0400, Steven Rostedt wrote: > > On Tue, 29 Sep 2020 13:33:40 +0200 > > Peter Zijlstra wrote: > > > > > Kim reported that perf-ftrace made his box unhappy. It turns out that > > > commit: > > > > > > ff5c4f5cad33 ("rcu/tree: Mark the idle relevant functions noinstr") > > > > > > removed one too many notrace. Probably due to there not being a helpful > > > comment. > > > > > > Reinstate the notrace and add a comment to avoid loosing it again. > > > > > > Fixes: ff5c4f5cad33 ("rcu/tree: Mark the idle relevant functions noinstr") > > > Reported-by: Kim Phillips > > > Signed-off-by: Peter Zijlstra (Intel) > > > --- > > > kernel/rcu/tree.c | 5 ++++- > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > > > index ee5e595501e8..33020d84ec6b 100644 > > > --- a/kernel/rcu/tree.c > > > +++ b/kernel/rcu/tree.c > > > @@ -1098,8 +1098,11 @@ noinstr bool __rcu_is_watching(void) > > > * CPU can safely enter RCU read-side critical sections. In other words, > > > * if the current CPU is not in its idle loop or is in an interrupt or > > > * NMI handler, return true. > > > + * > > > + * Must be notrace because __ftrace_ops_list_func() / ftrace_ops_assist_func() > > > + * will call this (for every function) outside of recursion protection. > > > */ > > > -bool rcu_is_watching(void) > > > +notrace bool rcu_is_watching(void) > > > { > > > bool ret; > > > > > > > I think the patch I suggested is more suitable. > > OK, I will let you guys fight it out. ;-) > Well, I think we should actually apply both, but the comment needs to be updated, as it will no longer be outside recursion. And the comment is wrong now as well, as its only outside recursion protection for the assist_func(). But it does prevent it from being always called for perf. * Make notrace because it can be called by the internal functions of * ftrace, and making this notrace removes unnecessary recursion calls. -- Steve