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: <20250715105041.6f63f4a5@batman.local.home>
Date: Tue, 15 Jul 2025 10:50:41 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: James Bottomley <James.Bottomley@...senPartnership.com>
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, 15 Jul 2025 10:38:34 -0400
James Bottomley <James.Bottomley@...senPartnership.com> wrote:

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

I think you just pointed out why Mathieu doesn't want to do this huge
update to merge upstream.


> 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

No you didn't say that, but I figured I'd mention it as it was likely
a thought someone may have had when reading your reply ;-)

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

I have no vested interest in it. Mathieu has just been very helpful for
the last several years with reviewing and improving the in-tree tracing
infrastructure (which LTTng received no benefit from), that I'm just
paying back the favor in trying to help him out.

-- Steve