linux-kernel - Re: [RFC] LTTng upstreaming next steps

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: <ccd1ace31a0fd27f033a1ec70df7c93aefebff3d.camel@HansenPartnership.com>
Date: Tue, 15 Jul 2025 10:38:34 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Mathieu Desnoyers
 <mathieu.desnoyers@...icios.com>, Steven Rostedt <rostedt@...nel.org>, Greg
 Kroah-Hartman <gregkh@...uxfoundation.org>, Christoph Hellwig
 <hch@...radead.org>, "Masami Hiramatsu (Google)" <mhiramat@...nel.org>,
 Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>, 
 Thomas Gleixner <tglx@...utronix.de>, linux-kernel
 <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] LTTng upstreaming next steps

On Tue, 2025-07-15 at 09:16 -0400, Steven Rostedt wrote:
> On Tue, 15 Jul 2025 08:50:08 -0400
> James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> > What's wrong with doing this the other way around?  i.e. making
> > ftrace and perf modules?  That way you could legitimately export
> > the symbol you're asking about and there would be way less out-of-
> > tree disadvantage to LTTng?  I know a lot of cloud people who would
> > be really happy if the tracing infrastructure were modular because
> > it would save us from having to boot different kernels to do in
> > depth problem analysis for otherwise locked down environments, so
> > they might be willing to invest in upstream development to help you
> > achieve this.
> 
> Well, if you can get those cloud people to invest in that work
> without causing any regressions, go for it.

I think you know as well as I no investment happens without some
indication of upstream being in favour, particularly for large changes.
So they're not going to invest in doing this on spec because it would
be unmaintainable out of tree and would be way more hassle than simply
having customers reboot as they do today.

> But I doubt it would be acceptable to make the ftrace tracing
> infrastructure into a module for the sole purpose of allowing LTTng
> to have EXPORT_SYMBOL_GPL().

I don't believe I said that: purpose is not monolithic in open source
because people do things for wildly different reasons which a clever
leader can stitch together into something more synergistically useful.
The cloud vendors would be invested solely for the purpose of being
able to load tracing infrastructure on demand (with the permission of
the tenant) into a running kernel.  They wouldn't care at all about the
symbol export problems of LTTng.  However, working with the cloud
vendors on what they want (and could be persuaded to invest in) would
give you what you wanted: an in-tree consumer for these symbols.

Regards,

James