linux-kernel - Re: [PATCH] tracing: remove tracing_is

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: <2024072525-declared-yam-0cad@gregkh>
Date: Thu, 25 Jul 2024 15:35:00 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-kernel@...r.kernel.org, Masami Hiramatsu <mhiramat@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: [PATCH] tracing: remove tracing_is_on export

On Thu, Jul 25, 2024 at 09:26:09AM -0400, Steven Rostedt wrote:
> On Thu, 25 Jul 2024 14:52:24 +0200
> Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> 
> > On Thu, Jul 25, 2024 at 08:31:02AM -0400, Steven Rostedt wrote:
> > > On Thu, 25 Jul 2024 11:36:08 +0200
> > > Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> > >   
> > > > The function tracing_is_on() is only called by in-kernel code, not by
> > > > any modules, so no need to export it as a symbol at all.  
> > > 
> > > Hmm, this is part of the debugging code along with:
> > > 
> > >  tracing_on();  tracing_off();
> > > 
> > > I had it exported in case a module needed to use it in debugging.  
> > 
> > What module?  There is no in-kernel user of it as a module that I could
> > find, what am I missing?
> >
> 
> Any module ;-)
> 
> It's for debugging. Just like trace_printk(). Something you would add to
> debug a module and then delete it before submitting. It's why I put the
> prototype into kernel.h. It's one of functions that can be handy during
> development. It's not supposed to be submitted into the kernel.
> 
> Granted, tracing_is_on() is probably the least likely one to be used, but I
> added it with the package, and I have actually used it for debugging a few
> times.

Generally, we don't allow symbols that are not actually being used in
the kernel tree?  tracing_is_on() is a "code flow" type of thing, where
code can operate differently if it is enabled or not.

And I would argue that tracing_on() and tracing_off() should also not be
allowed to be in a module, why would you want that?  Just enable/disable
it from userspace when doing your testing, IF you have permission to do
so.

thanks,

greg k-h