Re: [PING PATCH v7] kallsyms: new /proc/kallmodsyms with builtin modules

[Kris Van Hees]

Cc'ing Steven Rostedt as well since he was part of the original discussion
on the merits of this kallsyms enhancement.

On Tue, Feb 01, 2022 at 07:09:23PM -0800, Luis Chamberlain wrote:
> CC'ing bfptrace folks for feedback.
> 
> I'm pretty reluctant to merge any of this unless we have wide community
> desire to see this. I'm not quite seeing that yet.
> 
> On Wed, Jan 12, 2022 at 04:59:45PM +0000, Nick Alcock wrote:
> > On 12 Jan 2022, Luis Chamberlain stated:
> > 
> > > On Thu, Dec 16, 2021 at 08:19:12PM +0000, Nick Alcock wrote:
> > >> /proc/kallsyms is very useful for tracers and other tools that need to
> > >> map kernel symbols to addresses.
> > >> 
> > >> It would be useful
> > >
> > > It took me digging on archives to see to *who* this is useful to.
> > > The short answer seeme to be dtrace. Can you work on getting use
> > > of this for something (I don't know, maybe kernelshark?) that does
> > > not taint the kernel? Last I checked using dtrace on linux taints the
> > > kernel.
> > 
> > It hasn't tainted the kernel for at least four years :) v1 (with a
> > kernel module) has been GPLv2 since 2017; v2 is pure-BPF and has no
> > DTrace-specific kernel modules,
> 
> I google for dtrace LInux and I end up here:
> 
> https://www.oracle.com/linux/downloads/linux-dtrace.html
> 
> It then has documentation dating back to year 2020, and I can't
> apt-get install any of these "dtrace-utils" or anything with dtrace.
> 
> How do I get running with dtrace on debian? Typically this is a flag
> it has some funky license. You metioned dtrace is GPLv2 since 2017, does
> the same apply to the pure-BPF stuff?
> 
> Note I see a bpftrace effort, can that be made to use your changes?
> At *least* I can install that on a regular distro. And it notes
> "The bpftrace language is inspired by awk and C, and predecessor tracers
> such as DTrace and SystemTap."
> 
> I see on that page it says:
> 
> Note that DTrace requires the Unbreakable Enterprise Kernel (UEK)
> release 5 or higher. 
> 
> > just using some new things we have to
> > add to the kernel, most of which seem plausibly useful to others too
> > (kallmodsyms, waitfd pro tem until pidfd supports ptracers, and CTF).
> 
> All sounds nice, but I'd like to give this all a spin, but I can't
> find anything remotely close to anything sensible to try it out.
> I don't want to run any Oracle kernel. I want to run things upstream.
> 
> > This is not a DTrace-specific feature in any case: all my submissions
> > have noted that it seems likely to be useful to anyone who wants a
> > stable reference to modules that doesn't change whenever the kernel
> > config changes, which probably means most tracers with support for
> > kernel modules which implement anything like a programming language.
> 
> Great! But I'd like things to have tools
> 
> > > Without valid upstream users I see no need to add more complexity to the
> > > kernel. And complexity added by tainting modules or not upstream modules
> > 
> > We don't need any of those any more :) Even CTF is now generated by GCC
> > (once GCC 12 is released) and deduplicated by GNU ld: the CTF patch will
> > be only a few hundred lines long once GCC 12 is out and I drop the
> > DWARF->CTF translator.
> 
> Great!
> 
> > > Without a valid non-taining user being made very clear with a value-add,
> > > I will have to ignore this.
> > 
> > I hope this gives you a reason to not ignore it! Have some links:
> > 
> > DTrace v1 (maintenance mode, fairly hefty GPL kernel module, UPL
> > userspace; fully-functional including fbt, kernel side will shrink):
> > 
> >   https://github.com/oracle/dtrace-linux-kernel v1/5.15
> >   https://github.com/oracle/dtrace-utils 1.x-branch-dev
> > 
> > DTrace v2 based on BPF, in progress, some features still missing (UPL
> > userspace and a few GPL kernel patches, including this one: needs a BPF
> > cross-compiler, which is a new GCC 12 target):
> > 
> >   https://github.com/oracle/dtrace-linux-kernel v2/5.14.9
> >   https://github.com/oracle/dtrace-utils 2.0-branch
> 
> The "The Universal Permissive License (UPL)"? Really ? Anyway it seems
> to be at least GPL compatible. I'm curios why no distro has picked up
> any of this work?
> 
> I don't see much traction based on what you have said on dtrace
> on anything other than Oracle Linux stuff, it would be nice if bpftrace
> folks were excited about your changes and we had support for that
> there.
> 
> > (I'm going to respin all of these kernel branches against 5.17-rc once
> > the merge window closes, and bring the things both kernel trees have in
> > common into sync. I'll drop you a line once that's done.)
> 
> Nice.
> 
> > Config-wise both of these need kernels with CONFIG_KALLMODSYMS,
> > CONFIG_WAITFD and CONFIG_CTF turned on, and a kernel built with a 'make
> > ctf' done after 'make', and the kernel source tree available when DTrace
> > proper is built.
> 
> Thanks for the heads up.
> 
>   Luis