From: Alexei Starovoitov <ast@fb.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Alexei Starovoitov <ast@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>,
Daniel Borkmann <daniel@iogearbox.net>,
"x86@kernel.org" <x86@kernel.org>,
Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH v2 bpf-next 05/12] libbpf: auto-detect btf_id of raw_tracepoint
Date: Sat, 12 Oct 2019 00:40:13 +0000 [thread overview]
Message-ID: <0dbf83e8-10ec-cc17-c575-949639a7f018@fb.com> (raw)
In-Reply-To: <CAEf4BzZxQDUzYYjF091135d+O_fwZVdK9Dqw5H4_z=5QBqueYg@mail.gmail.com>
On 10/11/19 11:07 AM, Andrii Nakryiko wrote:
> On Wed, Oct 9, 2019 at 9:17 PM Alexei Starovoitov <ast@kernel.org> wrote:
>>
>> For raw tracepoint program types libbpf will try to find
>> btf_id of raw tracepoint in vmlinux's BTF.
>> It's a responsiblity of bpf program author to annotate the program
>> with SEC("raw_tracepoint/name") where "name" is a valid raw tracepoint.
>> If "name" is indeed a valid raw tracepoint then in-kernel BTF
>> will have "btf_trace_##name" typedef that points to function
>> prototype of that raw tracepoint. BTF description captures
>> exact argument the kernel C code is passing into raw tracepoint.
>> The kernel verifier will check the types while loading bpf program.
>>
>> libbpf keeps BTF type id in expected_attach_type, but since
>> kernel ignores this attribute for tracing programs copy it
>> into attach_btf_id attribute before loading.
>>
>> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
>> ---
>> tools/lib/bpf/bpf.c | 3 +++
>> tools/lib/bpf/libbpf.c | 17 +++++++++++++++++
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
>> index cbb933532981..79046067720f 100644
>> --- a/tools/lib/bpf/bpf.c
>> +++ b/tools/lib/bpf/bpf.c
>> @@ -228,6 +228,9 @@ int bpf_load_program_xattr(const struct bpf_load_program_attr *load_attr,
>> memset(&attr, 0, sizeof(attr));
>> attr.prog_type = load_attr->prog_type;
>> attr.expected_attach_type = load_attr->expected_attach_type;
>> + if (attr.prog_type == BPF_PROG_TYPE_RAW_TRACEPOINT)
>> + /* expected_attach_type is ignored for tracing progs */
>> + attr.attach_btf_id = attr.expected_attach_type;
>> attr.insn_cnt = (__u32)load_attr->insns_cnt;
>> attr.insns = ptr_to_u64(load_attr->insns);
>> attr.license = ptr_to_u64(load_attr->license);
>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>> index a02cdedc4e3f..8bf30a67428c 100644
>> --- a/tools/lib/bpf/libbpf.c
>> +++ b/tools/lib/bpf/libbpf.c
>> @@ -4586,6 +4586,23 @@ int libbpf_prog_type_by_name(const char *name, enum bpf_prog_type *prog_type,
>> continue;
>> *prog_type = section_names[i].prog_type;
>> *expected_attach_type = section_names[i].expected_attach_type;
>> + if (*prog_type == BPF_PROG_TYPE_RAW_TRACEPOINT) {
>> + struct btf *btf = bpf_core_find_kernel_btf();
>> + char raw_tp_btf_name[128] = "btf_trace_";
>> + char *dst = raw_tp_btf_name + sizeof("btf_trace_") - 1;
>> + int ret;
>> +
>> + if (IS_ERR(btf))
>> + /* lack of kernel BTF is not a failure */
>> + return 0;
>> + /* prepend "btf_trace_" prefix per kernel convention */
>> + strncat(dst, name + section_names[i].len,
>> + sizeof(raw_tp_btf_name) - (dst - raw_tp_btf_name));
>> + ret = btf__find_by_name(btf, raw_tp_btf_name);
>> + if (ret > 0)
>> + *expected_attach_type = ret;
>
> Well, actually, I realized after I gave Acked-by, so not yet :)
>
> This needs kernel feature probe of whether kernel supports specifying
> attach_btf_id, otherwise on older kernels we'll stop successfully
> loading valid program.
The code above won't find anything on older kernels.
The patch 1 of the series has to be there for proper btf to be
generated by pahole.
Before that happens expected_attach_type will stay zero
and corresponding copy in attach_btf_id will be zero as well.
I see no issues being compatible with older kernels.
> But even if kernel supports attach_btf_id, I think users still need to
> opt in into specifying attach_btf_id by libbpf. Think about existing
> raw_tp programs that are using bpf_probe_read() because they were not
> created with this kernel feature in mind. They will suddenly stop
> working without any of user's fault.
This one is excellent catch.
loop1.c should have caught it, since it has
SEC("raw_tracepoint/kfree_skb")
{
int nested_loops(volatile struct pt_regs* ctx)
.. = PT_REGS_RC(ctx);
and verifier would have rejected it.
But the way the test is written it's not using libbpf's autodetect
of program type, so everything is passing.
next prev parent reply other threads:[~2019-10-12 0:40 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-10 4:14 [PATCH v2 bpf-next 00/12] bpf: revolutionize bpf tracing Alexei Starovoitov
2019-10-10 4:14 ` [PATCH v2 bpf-next 01/12] bpf: add typecast to raw_tracepoints to help BTF generation Alexei Starovoitov
2019-10-10 4:14 ` [PATCH v2 bpf-next 02/12] bpf: add typecast to bpf helpers " Alexei Starovoitov
2019-10-10 4:14 ` [PATCH v2 bpf-next 03/12] bpf: process in-kernel BTF Alexei Starovoitov
2019-10-11 17:56 ` Andrii Nakryiko
2019-10-10 4:14 ` [PATCH v2 bpf-next 04/12] bpf: add attach_btf_id attribute to program load Alexei Starovoitov
2019-10-11 17:58 ` Andrii Nakryiko
2019-10-10 4:14 ` [PATCH v2 bpf-next 05/12] libbpf: auto-detect btf_id of raw_tracepoint Alexei Starovoitov
2019-10-11 18:02 ` Andrii Nakryiko
2019-10-11 18:07 ` Andrii Nakryiko
2019-10-12 0:40 ` Alexei Starovoitov [this message]
2019-10-12 1:29 ` Alexei Starovoitov
2019-10-12 4:38 ` Andrii Nakryiko
2019-10-12 4:53 ` Alexei Starovoitov
2019-10-12 4:39 ` Andrii Nakryiko
2019-10-10 4:14 ` [PATCH v2 bpf-next 06/12] bpf: implement accurate raw_tp context access via BTF Alexei Starovoitov
2019-10-11 18:31 ` Andrii Nakryiko
2019-10-11 23:13 ` Andrii Nakryiko
2019-10-10 4:14 ` [PATCH v2 bpf-next 07/12] bpf: attach raw_tp program with BTF via type name Alexei Starovoitov
2019-10-11 18:44 ` Andrii Nakryiko
2019-10-10 4:14 ` [PATCH v2 bpf-next 08/12] bpf: add support for BTF pointers to interpreter Alexei Starovoitov
2019-10-10 4:15 ` [PATCH v2 bpf-next 09/12] bpf: add support for BTF pointers to x86 JIT Alexei Starovoitov
2019-10-11 18:48 ` Andrii Nakryiko
2019-10-10 4:15 ` [PATCH v2 bpf-next 10/12] bpf: check types of arguments passed into helpers Alexei Starovoitov
2019-10-11 19:02 ` Andrii Nakryiko
2019-10-12 1:39 ` Alexei Starovoitov
2019-10-12 4:25 ` Andrii Nakryiko
2019-10-10 4:15 ` [PATCH v2 bpf-next 11/12] bpf: disallow bpf_probe_read[_str] helpers Alexei Starovoitov
2019-10-11 19:03 ` Andrii Nakryiko
2019-10-10 4:15 ` [PATCH v2 bpf-next 12/12] selftests/bpf: add kfree_skb raw_tp test Alexei Starovoitov
2019-10-10 11:07 ` Ido Schimmel
2019-10-10 19:07 ` Alexei Starovoitov
2019-10-11 19:05 ` Andrii Nakryiko
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=0dbf83e8-10ec-cc17-c575-949639a7f018@fb.com \
--to=ast@fb.com \
--cc=Kernel-team@fb.com \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=x86@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).