Re: [PATCH] tracing: remove tracing_is_on export
From: Greg Kroah-Hartman
Date: Fri Jul 26 2024 - 04:15:26 EST
On Thu, Jul 25, 2024 at 12:17:45PM -0400, Steven Rostedt wrote:
> On Thu, 25 Jul 2024 16:41:11 +0200
> Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> 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.
>
> It is mentioned, but I could expand on it more:
>
> Documentation/trace/ftrace.rst:
>
> tracing_on:
>
> This sets or displays whether writing to the trace
> ring buffer is enabled. Echo 0 into this file to disable
> the tracer or 1 to enable it. Note, this only disables
> writing to the ring buffer, the tracing overhead may
> still be occurring.
>
> The kernel function tracing_off() can be used within the
> kernel to disable writing to the ring buffer, which will
> set this file to "0". User space can re-enable tracing by
> echoing "1" into the file.
Seems "dangerous" that any random driver can control all of the tracing
system like this, but you do you :)
> > 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?
>
> Why add the burden of having to compile the core kernel to enable it? I use
> this all the time.
>
> > 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.
>
> This has been exported since 2008. Has it ever been a problem in the last
> 16 years?
As I am finding out, yes, external modules are "abusing" this to do
different types of logic depending on if tracing is enabled or not for
various unknown reasons. As there was no in-kernel user of this symbol,
I assumed it was just an oversight and should be removed.
I'll go ask the distro involved to just remove the symbol from their
kernels instead, but that feels like the wrong thing to do to me.
thanks,
greg k-h