Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp6258007ybf; Thu, 5 Mar 2020 16:43:41 -0800 (PST) X-Google-Smtp-Source: ADFU+vuamhHwug9M2ONnMq9ByAVPu0L21AwMCRjXoJdymnEFkSzVVpfE26sMbeIiua3GMfjxNfKT X-Received: by 2002:a9d:ed1:: with SMTP id 75mr474846otj.229.1583455421000; Thu, 05 Mar 2020 16:43:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583455420; cv=none; d=google.com; s=arc-20160816; b=SGeSarBBOO16y/B1izaaPPZx4KpaqTh3PB7dJvzlS9XGvvg16RXwkvy890G2he3x27 KmglZxTeFHwCPB51EeJNBvyLxrcvmUKDo0j+RrqaRS/FnCYMKm56MQbR1YA/jibZYAS4 3Opx4OO4Iu/dAmarW5um9NuExV5wnS1E0+nLXjOX3MytnPhjce24HdAC7mqzbUrhDqmb 8ICK4p1cp1yabUmb5P6gzyzDXHHwtevUtATwZXXsIzNxBnmj/FYGOCh0Ux6G3Z8NYcfL FAwJt6GNkqoXDqzDNgO2Tyyh1krn4jrqsC40JwF5oQpfPsNLxX5+HDrIcNa5y7oQfnjg 2z+A== 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; bh=VePD38gcOVzbg7AD+ga/UDsjd77hPrtuJP/uxdoR+ls=; b=DcKWAi8SdLde6iKeaKpeAi7QLbgE40H7vKmFJ/+Wxip+bxl98ywsQdRAUcjj5hmi2K UvQxHufWAy/hJ+fhpu/23DdMf9PIkGANCS1Es+xOvBo4bqkKPs+xaT+6S92qxzVtL/oZ mfkNCLFoecp8PlFzdaP1v0X8/mOPMhrFGbCCZV8n7xgWKt0oAhZZDXWoR3agfUNA3H/4 Rwf2gNsH1GB/oR5k781S/xLosUDdpsD8kAnVVJ+WcT3aXkpCDyMEbGlpqfVuUQwUNShw xLXDoY+Ckf8fWcqx676dx27HrYKumlxLSomCYILH/4+jC6gpOJGjDNr1ZcY6Tl3uWCYE hojQ== 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 l13si370333oil.161.2020.03.05.16.43.26; Thu, 05 Mar 2020 16:43: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 S1726300AbgCFAmq (ORCPT + 99 others); Thu, 5 Mar 2020 19:42:46 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:51786 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726128AbgCFAmq (ORCPT ); Thu, 5 Mar 2020 19:42:46 -0500 Received: from p5de0bf0b.dip0.t-ipconnect.de ([93.224.191.11] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jA14I-0000gb-53; Fri, 06 Mar 2020 01:42:22 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id 5E6A3104085; Fri, 6 Mar 2020 01:42:21 +0100 (CET) From: Thomas Gleixner To: Steven Rostedt , Joel Fernandes Cc: "Paul E. McKenney" , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, mingo@kernel.org, gregkh@linuxfoundation.org, gustavo@embeddedor.com, josh@joshtriplett.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, Masami Hiramatsu Subject: Re: [PATCH v2 3/9] rcu,tracing: Create trace_rcu_{enter,exit}() In-Reply-To: <20200213163800.5c51a5f1@gandalf.local.home> References: <20200212210139.382424693@infradead.org> <20200212210749.971717428@infradead.org> <20200212232005.GC115917@google.com> <20200213082716.GI14897@hirez.programming.kicks-ass.net> <20200213135138.GB2935@paulmck-ThinkPad-P72> <20200213164031.GH14914@hirez.programming.kicks-ass.net> <20200213185612.GG2935@paulmck-ThinkPad-P72> <20200213204444.GA94647@google.com> <20200213205442.GK2935@paulmck-ThinkPad-P72> <20200213211930.GG170680@google.com> <20200213163800.5c51a5f1@gandalf.local.home> Date: Fri, 06 Mar 2020 01:42:21 +0100 Message-ID: <87y2seb9g2.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Steven Rostedt writes: > rcu_nmi_enter() was marked NOKPROBE or other reasons. See commit Very well said: OR other reasons. I assume you meant 'for' but ... > c13324a505c77 ("x86/kprobes: Prohibit probing on functions before > kprobe_int3_handler()") > > The issue was that we must not allow anything in do_int3() call kprobe > code before kprobe_int3_handler() is called. Because ist_enter() (in > do_int3()) calls rcu_nmi_enter() it had to be marked NOKPROBE. It had > nothing to do with it being RCU nor NMI, but because it was simply > called in do_int3(). > > Thus, there's no reason to make rcu_nmi_exit() NOKPROBE. But a commont > to why rcu_nmi_enter() would probably be useful, like below: ... this is really wrong. While the int3 issue was the reason why it was marked NOKPROBE, fact is that aside of int3 problem (which is probably true for any other architecture using breakpoints for patching) any probe _before_ RCU is watching and _after_ RCU stopped watching is broken. Same applies for BPF and tracepoints which call into BPF or other nonsense. Can we please stop claiming that instrumentation can touch anything it wants and just admit that anything outside RCU covered regions is off-limits for instrumentation? Same applies for entry code and critical exceptions/traps. There is a reason why the tracer can't trace itself and there are very valid reasons to limit the instrumentation ability in other places. It's nice to be able to see into 'everything' but for 99.9999% of the cases the coverage of these things is absolutely irrelevant. Yes I know, "Correctness first" is this old school thing for grumpy old greybeards who are still stuck in the 90's. "Features first" is the new mantra. I deal with that every day by mopping up the mess it creates. Thanks, tglx