linux-kernel - Re: [PATCH 00/14] xfs: Remove unused trace events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250613113119.24943f6d@batman.local.home>
Date: Fri, 13 Jun 2025 11:31:19 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 linux-xfs@...r.kernel.org, Masami Hiramatsu <mhiramat@...nel.org>, Mathieu
 Desnoyers <mathieu.desnoyers@...icios.com>, Andrew Morton
 <akpm@...ux-foundation.org>, Carlos Maiolino <cem@...nel.org>, Christoph
 Hellwig <hch@....de>
Subject: Re: [PATCH 00/14] xfs: Remove unused trace events

On Fri, 13 Jun 2025 08:08:55 -0700
"Darrick J. Wong" <djwong@...nel.org> wrote:

> On Thu, Jun 12, 2025 at 05:24:05PM -0400, Steven Rostedt wrote:
> > 
> > Trace events take up to 5K in memory for text and meta data. I have code that  
> 
> Under what circumstances do they eat up that much memory?  And is that
> per-class?  Or per-tracepoint?

I just did an analysis of this:

  https://lore.kernel.org/lkml/20250613104240.509ff13c@batman.local.home/T/#md81abade0df19ba9062fd51ced4458161f885ac3

A TRACE_EVENT() is about 5K, and each DEFINE_EVENT() is about 1K.

> 
> > will trigger a warning when it detects unused tracepoints. The XFS file
> > system contains many events that are not called. Most of them used to be called
> > but due to code refactoring the calls were removed but the trace events stayed
> > behind.
> > 
> > Some events were added but never used. If they were recent, I just reported
> > them, but if they were older, this series simply removes them.  
> 
> TBH it'd be really nice if there was /something/ in the build path that
> would complain about disused tracepoints.  I often put in tracepoints
> while developing a feature, then the code gets massively rewritten
> during review, and none of us remember to rip out the orphaned traces...
> 

That's exactly what I'm doing. In the thread I did the analysis, it has
code that triggers a warning for unused events. I'm currently cleaning
them up (and asking others to do it too), so that I can add that code
without triggering all the current unused tracepoints.

Feel free to take those patches and it will warn at build time. Note,
it currently only works for built in code, so you have to build your
module as a built in and not a module.

> > One is called only when CONFIG_COMPACT is defined, so an #ifdef was placed
> > around it.
> > 
> > A couple are only called in #if 0 code (left as a reminder to fix it), so
> > those events are wrapped by a #if 0 as well (with a comment).
> > 
> > Finally, one event is supposed to be a trace event class, but was created with
> > the TRACE_EVENT() macro and not the DECLARE_EVENT_CLASS() macro. This works
> > because a TRACE_EVENT() is simply a DECLARE_EVENT_CLASS() and DEFINE_EVENT()
> > where the class and event have the same name. But as this was a mistake, the
> > event created should not exist.
> > 
> > Each patch is a stand alone patch. If you ack them, I can take them in my
> > tree, or if you want, you can take them. I may be adding the warning code to
> > linux-next near the end of the cycle, so it would be good to have this cleaned
> > up before hand. As this is removing dead code, it may be even OK to send them
> > to Linus as a fix.  
> 
> ...oh, you /do/ have a program and it's coming down the pipeline.
> Excellent <tents fingers>. :)

Ah you did notice ;-)

-- Steve