linux-kernel - Re: [RFC PATCH 2/5] unwind: Export unwind

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: <20250711100239.55434108@gandalf.local.home>
Date: Fri, 11 Jul 2025 10:02:39 -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:

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

BTW, when it comes to tracers, being out of tree is actually a huge
advantage. Tracers, unlike drivers, are only monitoring the kernel. Which
means it doesn't really rely on the workings of the kernel, so it really
doesn't get much help from changes made by other kernel developers. Like
the BPF folks have said keeping BPF programs up to date, isn't that much of
a burden.

The huge advantage that LTTng has over perf and ftrace for being out of
tree is that it controls the ABI between the LTTng kernel side and the user
space side. LTTng can experiment with new interfaces, and if something
breaks, it can simply change it and deliver a new tool that includes the
new module with the update.

One thing that perf and ftrace struggle with is getting the API correct the
first time. That's because they have no control over what other tools may use
their interface. If I expose something that another tool starts to use
(like powertop) and then I change it to enhance tracing and it breaks that
tool, that change gets reverted. To make any new update, I have to guess at
what are all the ways a tool could abuse this interface and also make sure
it works well into the future when new things come up. There's a lot of
interfaces I would love to change but can't, simply because they are now
ABI.

LTTng doesn't have the burden of worrying about "what other tool may use
this kernel interface?", and can even change it much later if Mathieu finds
a better way to do it.

-- Steve