From: Steven Rostedt <rostedt@goodmis.org>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org,
llvm@lists.linux.dev,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Masahiro Yamada <masahiroy@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Nicolas Schier <nicolas.schier@linux.dev>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v2 0/5] tracepoints: Add warnings for unused tracepoints and trace events
Date: Fri, 13 Jun 2025 08:07:41 -0400 [thread overview]
Message-ID: <20250613080741.55de0429@gandalf.local.home> (raw)
In-Reply-To: <14fc8777-a5d2-4877-9707-73c25d9e9bd3@infradead.org>
On Thu, 12 Jun 2025 20:20:48 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:
> Hi,
>
> On 6/12/25 4:58 PM, Steven Rostedt wrote:
> > Every trace event can take up to 5K of memory in text and meta data regardless
>
> s/meta data/metadata/ unless you are referring to meta's data.
Oh so I need to give Meta royalties?
>
> s/meta data/metadata/ in patches 1 and 2 also.
I'll update when I pull them in. Note, the cover letter isn't something
that I put into git. But I'll try to remember to update if I send a v3.
>
> > if they are used or not. Trace events should not be created if they are not
> > used. Currently there's over a hundred events in the kernel that are defined
> > but unused, either because their callers were removed without removing the
> > trace event with it, or a config hides the trace event caller but not the
> > trace event itself. And in some cases, trace events were simply added but were
> > never called for whatever reason. The number of unused trace events continues
> > to grow.
> >
> > This patch series aims to fix this.
> >
> > The first patch creates a new section called __tracepoint_check, where all
> > callers of a tracepoint creates a variable that is placed in this section with
> > a pointer to the tracepoint they use. Then on boot up, it iterates this
> > section and will modify the tracepoint's "func" field to a value of 1 (all
> > tracepoints "func" fields are initialized to NULL and is only set when they
> > are registered). This takes place before any tracepoint can be registered.
> >
> > Then each tracepoint is iterated on and if any tracepoint does not have its
> > "func" field set to 1 a warning is triggerd and every tracepoint that doesn't
>
> triggered
Yes I am!
>
> > have that field set is printed. The "func" field is then reset back to NULL.
> >
> > The second patch modifies scripts/sorttable.c to read the __tracepoint_check
> > section. It sorts it, and then reads the __tracepoint_ptr section that has all
> > compiled in tracepoints. It makes sure that every tracepoint is found in the
> > check section and if not, it prints a warning message about it. This lists the
> > missing tracepoints at build time.
> >
> > The third patch updates sorttable to work for arm64 when compiled with gcc. As
> > gcc's arm64 build doesn't put addresses in their section but saves them off in
> > the RELA sections. This mostly takes the work done that was needed to do the
> > mcount sorting at boot up on arm64.
> >
> > The forth patch adds EXPORT_TRACEPOINT() to the __tracepoint_check section as
>
> fourth (or are you coding in forth?)
oops
-- Steve
>
> > well. There was several locations that adds tracepoints in the kernel proper
> > that are only used in modules. It was getting quite complex trying to move
> > things around that I just decided to make any tracepoint in a
> > EXPORT_TRACEPOINT "used". I'm using the analogy of static and global
> > functions. An unused static function gets a warning but an unused global one
> > does not.
> >
> > The last patch updates the trace_ftrace_test_filter boot up self test. That
> > selftest creates a trace event to run a bunch of filter tests on it without
> > actually calling the tracepoint. To quiet the warning, the selftest tracepoint
> > is called within a if (!trace_<event>_enabled()) section, where it will not be
> > optimized out, nor will it be called.
> >
> > This is v2 from: https://lore.kernel.org/linux-trace-kernel/20250529130138.544ffec4@gandalf.local.home/
> > which was simply the first patch. This version adds the other patches.
> >
> > Steven Rostedt (5):
> > tracepoints: Add verifier that makes sure all defined tracepoints are used
> > tracing: sorttable: Add a tracepoint verification check at build time
> > tracing: sorttable: Find unused tracepoints for arm64 that uses reloc for address
> > tracepoint: Do not warn for unused event that is exported
> > tracing: Call trace_ftrace_test_filter() for the event
> >
> > ----
> > include/asm-generic/vmlinux.lds.h | 1 +
> > include/linux/tracepoint.h | 13 ++
> > kernel/trace/Kconfig | 31 +++
> > kernel/trace/trace_events_filter.c | 4 +
> > kernel/tracepoint.c | 26 +++
> > scripts/Makefile | 4 +
> > scripts/sorttable.c | 444 ++++++++++++++++++++++++++++++-------
> > 7 files changed, 437 insertions(+), 86 deletions(-)
> >
>
> thanks.
next prev parent reply other threads:[~2025-06-13 12:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-12 23:58 [PATCH v2 0/5] tracepoints: Add warnings for unused tracepoints and trace events Steven Rostedt
2025-06-12 23:58 ` [PATCH v2 1/5] tracepoints: Add verifier that makes sure all defined tracepoints are used Steven Rostedt
2025-06-12 23:58 ` [PATCH v2 2/5] tracing: sorttable: Add a tracepoint verification check at build time Steven Rostedt
2025-06-12 23:58 ` [PATCH v2 3/5] tracing: sorttable: Find unused tracepoints for arm64 that uses reloc for address Steven Rostedt
2025-06-12 23:58 ` [PATCH v2 4/5] tracepoint: Do not warn for unused event that is exported Steven Rostedt
2025-06-12 23:58 ` [PATCH v2 5/5] tracing: Call trace_ftrace_test_filter() for the event Steven Rostedt
2025-06-13 0:05 ` [PATCH v2 0/5] tracepoints: Add warnings for unused tracepoints and trace events Steven Rostedt
2025-06-13 3:20 ` Randy Dunlap
2025-06-13 12:07 ` Steven Rostedt [this message]
2025-06-13 14:28 ` Steven Rostedt
2025-06-13 14:42 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250613080741.55de0429@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=masahiroy@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=nicolas.schier@linux.dev \
--cc=rdunlap@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox