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: <2024072526-manned-ludicrous-1ce2@gregkh>
Date: Thu, 25 Jul 2024 16:41:11 +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:53:07AM -0400, Steven Rostedt wrote:
> On Thu, 25 Jul 2024 15:35:00 +0200
> Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> 
> > 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.
> 
> tracing_off() is key to development, and one that I would argue very much
> against removing. The other two are more just for "completeness".
> 
> It usually is used by adding a bunch of trace_printk(), and then:
> 
> 	if (condition) {
> 		trace_printk("Condition hit!\n");
> 		tracing_off();
> 	}
> 
> And then you run your kernel until you noticed that something weird
> happened. Then look at the trace file, and it will have all the events that
> happened up to the anomaly condition, and you don't have to worry about the
> ring buffer overflowing and losing your data.
> 
> This workflow is used by many developers.

Is it documented anywhere?  I've never heard of it before, and nothing
really describes this in Documentation/ that I can find.

But as you only want these to be exported to developer kernels, why not
say that and put that behind a debugging Kconfig option or something?
That way "vendor kernels" can properly disable this as they don't want
to give this type of functionality to random 3rd-party kernel modules.

thanks,

greg k-h