From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Alan Maguire <alan.maguire@oracle.com>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Alexei Starovoitov <ast@fb.com>,
Andrii Nakryiko <andrii@kernel.org>, bpf <bpf@vger.kernel.org>,
Networking <netdev@vger.kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Kernel Team <kernel-team@fb.com>
Subject: Re: one prog multi fentry. Was: [PATCH bpf-next] libbpf: support module BTF for BPF_TYPE_ID_TARGET CO-RE relocation
Date: Thu, 17 Dec 2020 10:22:43 -0800 [thread overview]
Message-ID: <20201217182243.vtpzqull76djt2qf@ast-mbp> (raw)
In-Reply-To: <alpine.LRH.2.23.451.2012171732410.2929@localhost>
On Thu, Dec 17, 2020 at 05:46:42PM +0000, Alan Maguire wrote:
>
>
> On Wed, 16 Dec 2020, Alexei Starovoitov wrote:
>
> > > > $ ksnoop "ip_send_skb(skb->sk)"
> > > >
> > > > ...will trace the skb->sk value. The user-space side of the program
> > > > matches the function/arg name and looks up the referenced type, setting it
> > > > in the function's map. For field references such as skb->sk, it also
> > > > records offset and whether that offset is a pointer (as is the case for
> > > > skb->sk) - in such cases we need to read the offset value via bpf_probe_read()
> > > > and use it in bpf_snprintf_btf() along with the referenced type. Only a
> > > > single simple reference like the above is supported currently, but
> > > > multiple levels of reference could be made to work too.
> >
> > Alan,
> >
> > I'm not sure why the last example is so different form the first two.
> > I think ksnoop tool will generate the program on the fly, right?
>
> Nope, the BPF program is hard-coded; it adapts to different functions
> through use of the map entries describing function signatures and their
> BTF ids, and other associated tracing info. The aim is to provide a
> generic tracing tool which displays kernel function arguments but
> doesn't require LLVM/clang on the target, just a kernel built with BTF
> and libbpf. Sorry this wasn't clearer in my explanation; I'm working
> on rewriting the code and will send it out ASAP.
>
> > So it can generate normal LDX insn with CO-RE relocation (instead of bpf_probe_read)
> > to access skb->sk. It can also add relo for that LDX to point to
> > struct sk_buff's btf_id defined inside prog's BTF.
> > The 'sk' offset inside bpf program and inside BTF can be anything: 0, 4, ...
> > libbpf relocation logic will find the right offset in kernel's sk_buff.
> > If ksnoop doesn't have an ability to parse vmlinux.h file or kernel's BTF
> > it can 'cheat'.
> > If the cmdline looks like:
> > $ ksnoop "ip_send_skb(skb->sk)"
> > It can generate BTF:
> > struct sk_buff {
> > struct sock *sk;
> > };
> >
> > If cmdline looks like:
> > $ ksnoop "ip_send_skb(skb->sock)"
> > It can generate BTF:
> > struct sk_buff {
> > struct sock *sock;
> > };
> > Obviously there is no 'sock' field inside kernel's struct sk_buff, but tool
> > doesn't need to care. It can let libbpf do the checking and match
> > fields properly.
> >
> > > > into that a bit more if you don't mind because I think some form of
> > > > user-space-specified BTF ids may be the easiest approach for more flexible
> > > > generic tracing that covers more than function arguments.
> >
> > I think you're trying to figure out kernel's btf_ids in ksnoop tool.
>
> Yep.
>
> > I suggest to leave that job to libbpf. Generate local BTFs in ksnoop
> > with CO-RE relocs and let libbpf handle insn patching.
> > No FDs to worry about from ksnoop side either.
> >
>
> The current approach doesn't rely on instruction patching outside
> of limited CORE use around struct pt_regs fields (args, IP, etc)
> which shouldn't require LLVM/clang availability on the target system.
I'm not suggesting to use clang.
Everything I proposed above is for ksnoop to do. Not for the clang.
prev parent reply other threads:[~2020-12-17 18:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-05 2:51 [PATCH bpf-next] libbpf: support module BTF for BPF_TYPE_ID_TARGET CO-RE relocation Andrii Nakryiko
2020-12-06 0:37 ` Alan Maguire
2020-12-08 3:28 ` Andrii Nakryiko
2020-12-08 22:02 ` Alan Maguire
2020-12-07 16:38 ` Alan Maguire
2020-12-08 3:12 ` Alexei Starovoitov
2020-12-08 3:40 ` Andrii Nakryiko
2020-12-08 22:13 ` Alan Maguire
2020-12-08 23:39 ` Alexei Starovoitov
2020-12-09 23:21 ` Alan Maguire
2020-12-15 22:38 ` one prog multi fentry. Was: " Alexei Starovoitov
2020-12-16 16:18 ` Alan Maguire
2020-12-16 22:27 ` Andrii Nakryiko
2020-12-17 7:16 ` Alexei Starovoitov
2020-12-17 17:46 ` Alan Maguire
2020-12-17 18:22 ` Alexei Starovoitov [this message]
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=20201217182243.vtpzqull76djt2qf@ast-mbp \
--to=alexei.starovoitov@gmail.com \
--cc=alan.maguire@oracle.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--cc=netdev@vger.kernel.org \
/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).