Message-ID: <20250711133240.0d5b6de8@batman.local.home>
Date: Fri, 11 Jul 2025 13:32:40 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Christoph Hellwig <hch@...radead.org>, Mathieu Desnoyers
 <mathieu.desnoyers@...icios.com>, linux-kernel@...r.kernel.org, Josh
 Poimboeuf <jpoimboe@...nel.org>, Masami Hiramatsu <mhiramat@...nel.org>,
 Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>, Jiri
 Olsa <jolsa@...nel.org>, Namhyung Kim <namhyung@...nel.org>, Thomas
 Gleixner <tglx@...utronix.de>, Andrii Nakryiko <andrii@...nel.org>, Indu
 Bhagat <indu.bhagat@...cle.com>, "Jose E. Marchesi" <jemarch@....org>, Beau
 Belgrave <beaub@...ux.microsoft.com>, Jens Remus <jremus@...ux.ibm.com>,
 Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton
 <akpm@...ux-foundation.org>, tech-board-discuss@...ts.linuxfoundation.org
Subject: Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL
 modules

On Fri, 11 Jul 2025 18:39:40 +0200
Greg KH <gregkh@...uxfoundation.org> wrote:

> > Yes, but you mostly see drivers and side functions that really do nothing
> > for the kernel. LTTng has contributed tracepoints, several RCU
> > enhancements, restartable sequences and more.  
> 
> Somehow those little drivers are "doing something" for the kernel by
> virtue of you being able to use your keyboard and network card :)

I meant contributions to other parts of the kernel than just tracing.
This is more like PREEMPT_RT, where improvements to the core kernel was
made to help both LTTng and the kernel proper.

If you want to talk about precedent, we have it. raw_spin_lock() was
used *only* for PREEMPT_RT years before it was ever added to the kernel.

> 
> Seriously, don't conflate tracing core code as some how being more
> "important" than any existing driver in the tree, when both, in the end,
> are necessary for a user to get their job done.  One could even say that
> the tracing stuff is NOT needed, as if code works properly, no one
> should be needing to use it...

I'll even argue that this is fine for EXPORT_SYMBOL_GPL() because it
*isn't important*! I'm not saying it's more important. I'll agree with
you and say its less important. The point that the function I want to
export gives you information only and doesn't give you any operational
hooks into the kernel, means it's just a outside observer of the
system. It's not changing how the system works in any way.

I always tell people that tracing is a second class citizen when it
comes to the kernel. It should try it's damn best to not effect the
system it is trying to observe. If there's a decision to be made that
can improve tracing with the cost of hurting the system performance
when tracing is off, I'll make the decision not to do it. This is why
we have jump_label. To have nops when tracing is disabled and jmps when
it is, so that tracing doesn't affect normal operations. Not to mention
all the hacks done for function tracing to keep its overhead down to a
bare minimum.

> 
> Anyway, I see stuff all over the place, not just drivers, for "real"
> things on a weekly basis.  Go poke in the Android kernel tree if you
> want to see loads of examples of where vendors feel they can export/hook
> into core parts of Linux just to get their work done.  I would argue
> that most of them are NOT needed and are doing crazy things, but as
> users have real hardware that sometimes requires it, it's a hard thing
> to argue against.

I know you see real things. I think you misunderstood my comment. I
didn't mean to say what you see is anyway less than what happens in
core kernel. I find drivers are a key part of the kernel. The core
kernel is just a tool to have applications interact with the hardware,
and without drivers, the kernel is useless. My point was merely stating
that you and I have different view points of the kernel. I in no way
was saying mine was more important. In fact, I would say it's less
important.

> 
> I'll show one real-world example, the USB offload path code, that you
> are using today on your Android phones that saves loads of battery life.
> In older kernels, the hooks/exports needed for that were all over the
> place, it took an engineer years to get this all working for lots of
> different hardware types and merged upstream properly.  They knew that
> they could not just get the upstream developers to export the needed
> functions, they had to get their working code merged in order to be able
> to have it happen.  And they did!

I'm not sure how that is comparable? It sounds like they needed to
clean up a bunch of other code for other hardware so they could use
this feature.

The feature I'm talking about is fully available. It's just a way to
get a user space stack trace from the kernel. Nothing more. The work
being done is to make it generic so all the tracers could use it. All
that's upstream. The two functions I would like to export is "give me a
user space stack trace now" and "defer the user space stack trace
from NMI to when the task goes back to user space".

> 
> That was a non-trivial task, and while you might not feel it "does
> nothing", the power savings you rely on daily would beg to differ.
> 
> So get the lttng code merged into the tree please, it seems that you are
> the one objecting to the merge, not me :)

It was actually others, and it was years ago. Perhaps we could just
accept the LTTng kernel module as is, as a module, and leave it at that?

Then these functions would still have to be EXPORT_SYMBOL_GPL() but at
least it would be for an in-tree module.

-- Steve

Powered by blists - more mailing lists