Received: by 10.192.165.148 with SMTP id m20csp908496imm; Fri, 27 Apr 2018 09:23:40 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpPsNwg/daP6e5RCKC1RVmxYipXWRbg+YgWC6/wGn281hGmKP54tqWyWIU4Yw+oxDaXYv5S X-Received: by 10.167.130.151 with SMTP id s23mr2759620pfm.106.1524846220765; Fri, 27 Apr 2018 09:23:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524846220; cv=none; d=google.com; s=arc-20160816; b=NltEI/adQ4+6xkX/Tdvvo/GjtpRnj02fyS0Bj2/9voLSORlD7pEw5v+SNb2jtqy762 HD9eRG/rR5us//3KhI0IpgzFolhzXOMzZdhDdMW0g3xdgoTagIJKpa7dua4QCC454lXL ZxsLkpJWIDaK/ZQ6Ouf0dMtf3oivNN2UDN4eEEhlsoS4bYhLCrjdOvw7eRstnIivQ8qL egL5hVDkgwY/S0giXNdvHYyyKatA/DqZawr7M/sa1A2WTL1MlUWhzBnqJvm6WCSAJV3P G36ydUi22bVwM+bzia/1ejgIYPVcVGmygu9ZVscizPT5kyb2AzQ7gzshUoNqjCBiAh81 Ii0w== 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=eyjd/SCoFxVLmCbfO5Dw8qeV4jLXaxiWmfIhvLcde9I=; b=0Np9iYI0LbLYAXRLF5YzpVWDnKcwO12DLYsmhmoSmZGX8RflFpDvyTdH8MFlZs0IFJ 7D6fOnoQJcc04XQPfxWF5cRm6RE6MukjriZzHlxAk91k2htShXdyMNQbHpLRPPpnAQVn X5sRpoAamCrSTmfiFSl9geYO62S7QYSyG2BkkmsQfPmfhQBBqWqQE+WGozHXrrEQ9dI4 nI+LS2LuCNcLY0cyrp97mVQhcKY9ZyilSDLKg2zPi6otIUHnGuuke05GUOUHnFP0agSl CFB2VPMkFFIKKLlw8B/oor8qvW+VoOKvMItD3ATZRvylurxS0TAU0IcYkz/Ro58b5pip L+8Q== 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 o7-v6si1453503pgc.381.2018.04.27.09.23.26; Fri, 27 Apr 2018 09:23:40 -0700 (PDT) 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 S932930AbeD0QWG (ORCPT + 99 others); Fri, 27 Apr 2018 12:22:06 -0400 Received: from mail.kernel.org ([198.145.29.99]:52334 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932802AbeD0QWF (ORCPT ); Fri, 27 Apr 2018 12:22:05 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (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 D3B8D218C9; Fri, 27 Apr 2018 16:22:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D3B8D218C9 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: Fri, 27 Apr 2018 12:22:01 -0400 From: Steven Rostedt To: Joel Fernandes Cc: Paul McKenney , LKML , Peter Zilstra , Ingo Molnar , Mathieu Desnoyers , Tom Zanussi , Namhyung Kim , Thomas Glexiner , Boqun Feng , Frederic Weisbecker , Randy Dunlap , Masami Hiramatsu , Fenguang Wu , Baohong Liu , Vedang Patel , "Cc: Android Kernel" Subject: Re: [PATCH RFC] tracepoint: Introduce tracepoint callbacks executing with preempt on Message-ID: <20180427122201.75abc313@gandalf.local.home> In-Reply-To: References: <20180427042656.190746-1-joelaf@google.com> <20180427155701.GL26088@linux.vnet.ibm.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; 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 On Fri, 27 Apr 2018 09:14:30 -0700 Joel Fernandes wrote: > > Hmmm... Do I need to create a _notrace variant of srcu_read_lock() > > and srcu_read_unlock()? > > That shouldn't be needed. For the rcu_read_lock_sched case, there is a > preempt_disable which needs to be a notrace, but for the srcu one, > since we don't do that, I think it should be fine. Actually, I think I may agree here too. Because the _notrace is for function tracing, and it shouldn't affect it. If people don't want it traced, they could add those functions to the list in the notrace file. -- Steve