Message-ID: <20250711091734.5632dcf7@gandalf.local.home>
Date: Fri, 11 Jul 2025 09:17:34 -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 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()?

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

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

The user stack unwinding that we are adding is a new feature to do stack
unwinding without frame pointers that Fedora is working on adding. There's
two functions that LTTng would need to get this, and both will be used by
ftrace and perf. It only gives the module a user stack unwind. It's
information only and not something that tweaks the kernel in any way.

-- Steve

Powered by blists - more mailing lists