Message-ID: <2025071127-reunion-residence-c0f2@gregkh>
Date: Fri, 11 Jul 2025 18:39:40 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Steven Rostedt <rostedt@...dmis.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, Jul 11, 2025 at 09:17:34AM -0400, Steven Rostedt wrote:
> On Fri, 11 Jul 2025 13:38:07 +0200
> Greg KH <gregkh@...uxfoundation.org> wrote:
> 
> > On Fri, Jul 11, 2025 at 06:57:42AM -0400, Steven Rostedt wrote:
> > > 
> > > [ Adding the TAB to this as well ]
> > > 
> > > On Fri, 11 Jul 2025 00:36:28 -0700
> > > Christoph Hellwig <hch@...radead.org> wrote:
> > >   
> > > > On Wed, Jul 09, 2025 at 05:25:49PM -0400, Mathieu Desnoyers wrote:  
> > > > > Allow the unwind_user symbol to be used by GPL modules, for instance
> > > > > LTTng.    
> > > > 
> > > > I don't see a LTTng submission or any other user in this series.
> > > > So the usual prohibition against adding unused exports applies here
> > > > as usual.  
> > > 
> > > I want to bring up this discussion. I understand there's a policy not to
> > > add EXPORT_SYMBOL_GPL() unless there's a current user of it in the kernel
> > > proper. My question is, does this policy have to be draconian?  
> > 
> > It's not "draconian", it is "we do not add exports for stuff that is
> > not in our kernel tree."  Simple, direct, and obvious.  We have no idea
> > how, or if, external modules do anything with apis that we export and do
> > not use internally, so we can't change them without breaking anything,
> > so it's simpler and more obvious to not even attempt to care about them.
> 
> Let me clear up a misunderstanding on my part. That is, this *will* be used
> internally when an EXPORT_SYMBOL_GPL() is added to it. Ftrace, perf and
> probably BPF will be using the function. But all of these are not modules,
> but the only one that is a module would be LTTng, and it is adaptable to
> change. Just like a BPF program would be.
> 
> I mean, if I made a part of ftrace into a loadable module that used this
> feature, then we could make this EXPORT_SYMBOL_GPL()?

Don't be silly, and don't attempt to "skirt the rules" like this.
Otherwise you will have a huge onflux of people/companies claiming that
they too deserve symbol exports for their long-out-of-tree-monstrosities
that they never worked to merge.

Again, let's keep the rule simple, exports are only for in-kernel users.

> > If external users want to use a symbol, they should get merged into the
> > tree.
> > 
> > Yes, lttng is a "good citizen" of the kernel community, and yes, it's
> > not merged into the tree, but that's not our issue, and living outside
> > of the tree has it's penalities, both economic and technical.  This is
> > one of those penalities, sorry.
> 
> But it is our issue. We are the ones keeping it out. We can try to get it
> in again, but it will be a long and tedious process. Mathieu is at a
> disadvantage here because he has no leverage as most of his customers are
> non-kernel developers. So the decisions he makes is for them, not us. And
> this has caused tension when it came to the way he did things compared to
> what we wanted. His keeping it out of tree has worked so far. And now he's
> been an active contributor on a new feature that will benefit perf, ftrace
> and BPF but because we've been keeping him out of tree, he doesn't get to
> use the work he's contributed to?

Sure he can, by virtue of it being in perf, ftrace, and bpf :)

Again, export stuff for in-tree users only.

> > So no, we shouldn't change this at all.  And I think we need to start
> > doing more of the "only export this symbol for this subsystem/module"
> > trimming as well.  I see the horrors that out-of-tree kernel code does
> > and by removing the ability of them to even get access to the things
> > they do have access to today, would be good for everyone involved (i.e.
> > our community, AND the users of Linux to allow them to have a more
> > stable and trustworthy base to rely on.)
> 
> 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 :)

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...

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'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!

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 :)

thanks,

greg k-h

Powered by blists - more mailing lists