From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754798AbcKUUMm (ORCPT ); Mon, 21 Nov 2016 15:12:42 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:47429 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753809AbcKUUMj (ORCPT ); Mon, 21 Nov 2016 15:12:39 -0500 Date: Mon, 21 Nov 2016 12:12:35 -0800 From: "Paul E. McKenney" To: Steven Rostedt Cc: Peter Zijlstra , Andi Kleen , Jiri Olsa , linux-kernel@vger.kernel.org, Ingo Molnar , Josh Triplett , Jan Stancek Subject: Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage! Reply-To: paulmck@linux.vnet.ibm.com References: <20161121005343.GB1891@krava> <20161121092850.GF3102@twins.programming.kicks-ass.net> <20161121170612.GT26852@two.firstfloor.org> <20161121171853.GK3092@twins.programming.kicks-ass.net> <20161121125501.768ae998@gandalf.local.home> <20161121132438.2440d82f@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161121132438.2440d82f@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16112120-0004-0000-0000-000010E6ABFB X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006118; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000189; SDB=6.00783554; UDB=6.00378407; IPR=6.00561173; BA=6.00004898; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013398; XFM=3.00000011; UTC=2016-11-21 20:12:35 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16112120-0005-0000-0000-00007AC4A81B Message-Id: <20161121201235.GX3612@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-21_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611210335 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 21, 2016 at 01:24:38PM -0500, Steven Rostedt wrote: > > Paul, > > > On Mon, 21 Nov 2016 12:55:01 -0500 > Steven Rostedt wrote: > > > On Mon, 21 Nov 2016 18:18:53 +0100 > > Peter Zijlstra wrote: > > > > > Its not ftrace as such though, its RCU, ftrace simply uses RCU to avoid > > > locking, as one does. > > > > Just to be clear, as ftrace in the kernel mostly represents function > > tracing, which doesn't use RCU. This is a tracepoint feature. > > > > > > > > Biggest objection would be that the rcu_irq_enter_irqson() thing does > > > POPF and rcu_irq_exit_irqson() does again. So wrapping every tracepoint > > > with that is quite a few cycles. > > > > Agree. Even though this ends up being a whack-a-mole(TM) fix, I'm not > > concerned enough to put a heavy weight rcu idle code in for all > > tracepoints. > > > > Although, what about a percpu flag that can be checked in the > > tracepoint code to see if it should enable RCU or not? > > > > Hmm, I wonder if "rcu_is_watching()" is light enough to have in all > > tracepoints? > > Is it possible to make rcu_is_watching() an inlined call to prevent the > overhead of doing a function call? This way we could use this in the > fast path of the tracepoint. It would mean exposing the rcu_dynticks structure to the rest of the kernel, but I guess that wouldn't be the end of the world. Are you calling rcu_is_watching() or __rcu_is_watching()? The latter is appropriate if preemption is already disabled. Thanx, Paul