Message-ID: <20250613080741.55de0429@gandalf.local.home>
Date: Fri, 13 Jun 2025 08:07:41 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Randy Dunlap <rdunlap@...radead.org>
Cc: linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
 llvm@...ts.linux.dev, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Masami Hiramatsu <mhiramat@...nel.org>, Arnd Bergmann <arnd@...db.de>,
 Masahiro Yamada <masahiroy@...nel.org>, Nathan Chancellor
 <nathan@...nel.org>, Nicolas Schier <nicolas.schier@...ux.dev>, Nick
 Desaulniers <nick.desaulniers+lkml@...il.com>, Catalin Marinas
 <catalin.marinas@....com>, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2 0/5] tracepoints: Add warnings for unused tracepoints
 and trace events

On Thu, 12 Jun 2025 20:20:48 -0700
Randy Dunlap <rdunlap@...radead.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.

Powered by blists - more mailing lists