From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7640CC4741F for ; Fri, 25 Sep 2020 21:18:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EF40723730 for ; Fri, 25 Sep 2020 21:18:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EF40723730 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1BBD36B006E; Fri, 25 Sep 2020 17:18:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C97C56B0074; Fri, 25 Sep 2020 17:18:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A76FF6B006C; Fri, 25 Sep 2020 17:18:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0232.hostedemail.com [216.40.44.232]) by kanga.kvack.org (Postfix) with ESMTP id 838B86B006C for ; Fri, 25 Sep 2020 17:18:23 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 4EF123652 for ; Fri, 25 Sep 2020 21:18:23 +0000 (UTC) X-FDA: 77302847286.15.order86_2511da22716a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin15.hostedemail.com (Postfix) with ESMTP id E43A61814B0C8 for ; Fri, 25 Sep 2020 21:18:22 +0000 (UTC) X-HE-Tag: order86_2511da22716a X-Filterd-Recvd-Size: 4012 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Fri, 25 Sep 2020 21:18:22 +0000 (UTC) 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 7A86D208B6; Fri, 25 Sep 2020 21:18:21 +0000 (UTC) Received: from rostedt by gandalf.local.home with local (Exim 4.94) (envelope-from ) id 1kLv6h-002CsX-Ny; Fri, 25 Sep 2020 17:18:19 -0400 Message-ID: <20200925211206.423598568@goodmis.org> User-Agent: quilt/0.66 Date: Fri, 25 Sep 2020 17:12:06 -0400 From: Steven Rostedt To: linux-kernel@vger.kernel.org Cc: Yafang Shao , Axel Rasmussen , Andrew Morton , Vlastimil Babka , Michel Lespinasse , Daniel Jordan , Davidlohr Bueso , Linux MM , Ingo Molnar , Joonsoo Kim Subject: [PATCH 0/3 v2] tracing/mm: Add tracepoint_enabled() helper function for headers X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Tracepoints are not safe to be called directly from header files as they may be included by C code that has CREATE_TRACE_POINTS defined, and this would cause side effects and possibly break the build in hard to debug ways. Not to mention it also will bloat the code being in commonly used inline functions. Instead, it is recommended to call a tracepoint helper function that is defined in a C file that calls the tracepoint. But we would only want this function to be called if the tracepoint is enabled, as function calls add overhead. The trace__enabled() function is also not safe to be called in a header file as it is created by the tracepoint header, which suffers the same fate if CREATE_TRACE_POINTS is defined. Instead, the tracepoint needs to be declared as an extern, and the helper function can test the static key to call the helper function that calls the tracepoint. This has been done by open coding the tracepoint extern and calling the static key directly: commit 95813b8faa0cd ("mm/page_ref: add tracepoint to track down page reference manipulation") commit 7f47d8cc039f ("x86, tracing, perf: Add trace point for MSR accesses") does this (back in 2015). Now we have another use case, so a helper function should be created to keep the internals of the tracepoints from being spread out in other subsystems. Link: https://lore.kernel.org/r/20200922125113.12ef1e03@gandalf.local.home This adds tracepoint_enabled() helper macro and DECLARE_TRACEPOINT() macro to allow this to be done without exposing the internals of the tracepoints. The first patch adds the infrastructure, the second converts page_ref over to it, and third converts over msr.h. Steven Rostedt (VMware) (3): tracepoints: Add helper to test if tracepoint is enabled in a header mm/page_ref: Convert the open coded tracepoint enabled to the new helper x86: Use tracepoint_enabled() for msr tracepoints instead of open coding it ---- Changes since v1 (https://lore.kernel.org/r/20200924170928.466191266@goodmis.org): - Fixed using "trace_enabled()" instead of "tracepoint_enabled()" (Mathieu Desnoyers reported) - Reworded to include comments about bloating the kernel when tracepoints are used in commonly used inlined functions. - Added the msr update as well. Documentation/trace/tracepoints.rst | 27 ++++++++++++++++++++++++ arch/x86/include/asm/msr.h | 18 +++++++--------- include/linux/page_ref.h | 42 ++++++++++++++++++------------------- include/linux/tracepoint-defs.h | 34 ++++++++++++++++++++++++++++++ 4 files changed, 90 insertions(+), 31 deletions(-)