linux-modules.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kris Van Hees <kris.van.hees@oracle.com>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: Nick Alcock <nick.alcock@oracle.com>, bas smit <bas@baslab.org>,
	Tom??? Glozar <tglozar@gmail.com>,
	Ast-x64 <Ast-x64@protonmail.com>,
	Viktor Malik <viktor.malik@gmail.com>, Daniel Xu <dxu@dxuuu.xyz>,
	Jiri Olsa <jolsa@kernel.org>,
	jeyu@kernel.org, masahiroy@kernel.org,
	linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
	arnd@arndb.de, akpm@linux-foundation.org, eugene.loh@oracle.com,
	kris.van.hees@oracle.com, Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PING PATCH v7] kallsyms: new /proc/kallmodsyms with builtin modules
Date: Tue, 1 Feb 2022 22:39:05 -0500	[thread overview]
Message-ID: <20220202033905.GK18312@oracle.com> (raw)
In-Reply-To: <Yfn145FyE3PDBEad@bombadil.infradead.org>

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

  reply	other threads:[~2022-02-02  3:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-16 20:19 [PING PATCH v7] kallsyms: new /proc/kallmodsyms with builtin modules Nick Alcock
2021-12-16 20:19 ` [PATCH v7 1/7] kbuild: bring back tristate.conf Nick Alcock
2021-12-16 20:19 ` [PATCH v7 2/7] kbuild: add modules_thick.builtin Nick Alcock
2021-12-16 20:19 ` [PATCH v7 3/7] kbuild: generate an address ranges map at vmlinux link time Nick Alcock
2021-12-16 20:19 ` [PATCH v7 4/7] kallsyms: introduce sections needed to map symbols to built-in modules Nick Alcock
2021-12-16 20:19 ` [PATCH v7 5/7] kallsyms: optimize .kallsyms_modules* Nick Alcock
2021-12-16 20:19 ` [PATCH v7 6/7] kallsyms: add /proc/kallmodsyms Nick Alcock
2021-12-16 20:19 ` [PATCH v7 7/7] kallsyms: add reliable symbol size info Nick Alcock
2021-12-19 14:05   ` [kallsyms] a42fff4e29: leaking-addresses.proc.kallmodsyms.0T_stext kernel test robot
2022-01-12 16:30 ` [PING PATCH v7] kallsyms: new /proc/kallmodsyms with builtin modules Luis Chamberlain
2022-01-12 16:59   ` Nick Alcock
2022-02-02  3:09     ` Luis Chamberlain
2022-02-02  3:39       ` Kris Van Hees [this message]
2022-02-02 18:10       ` Daniel Xu
2022-02-03 14:11         ` Nick Alcock
2022-02-02 18:37       ` Jiri Olsa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220202033905.GK18312@oracle.com \
    --to=kris.van.hees@oracle.com \
    --cc=Ast-x64@protonmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=bas@baslab.org \
    --cc=dxu@dxuuu.xyz \
    --cc=eugene.loh@oracle.com \
    --cc=jeyu@kernel.org \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=nick.alcock@oracle.com \
    --cc=rostedt@goodmis.org \
    --cc=tglozar@gmail.com \
    --cc=viktor.malik@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).