bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yonghong Song <yhs@fb.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Andrii Nakryiko <andrii@kernel.org>, bpf <bpf@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	Alexei Starovoitov <ast@fb.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Kernel Team <kernel-team@fb.com>,
	Christopher William Snowhill <chris@kode54.net>
Subject: Re: [PATCH bpf 2/2] libbpf: allow loading empty BTFs
Date: Mon, 11 Jan 2021 17:15:54 -0800	[thread overview]
Message-ID: <31ebd16f-8218-1457-b4e2-3728ab147747@fb.com> (raw)
In-Reply-To: <CAEf4BzZhFrHho-F+JyY6wQyWUZ+0cJJLkGv+=DHP4equkkm4iw@mail.gmail.com>



On 1/11/21 12:51 PM, Andrii Nakryiko wrote:
> On Mon, Jan 11, 2021 at 10:13 AM Yonghong Song <yhs@fb.com> wrote:
>>
>>
>>
>> On 1/9/21 11:03 PM, Andrii Nakryiko wrote:
>>> Empty BTFs do come up (e.g., simple kernel modules with no new types and
>>> strings, compared to the vmlinux BTF) and there is nothing technically wrong
>>> with them. So remove unnecessary check preventing loading empty BTFs.
>>>
>>> Reported-by: Christopher William Snowhill <chris@kode54.net>
>>> Fixes: ("d8123624506c libbpf: Fix BTF data layout checks and allow empty BTF")
>>> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
>>> ---
>>>    tools/lib/bpf/btf.c | 5 -----
>>>    1 file changed, 5 deletions(-)
>>>
>>> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
>>> index 3c3f2bc6c652..9970a288dda5 100644
>>> --- a/tools/lib/bpf/btf.c
>>> +++ b/tools/lib/bpf/btf.c
>>> @@ -240,11 +240,6 @@ static int btf_parse_hdr(struct btf *btf)
>>>        }
>>>
>>>        meta_left = btf->raw_size - sizeof(*hdr);
>>> -     if (!meta_left) {
>>> -             pr_debug("BTF has no data\n");
>>> -             return -EINVAL;
>>> -     }
>>
>> Previous kernel patch allows empty btf only if that btf is module (not
>> base/vmlinux) btf. Here it seems we allow any empty non-module btf to be
>> loaded into the kernel. In such cases, loading may fail? Maybe we should
>> detect such cases in libbpf and error out instead of going to kernel and
>> get error back?
> 
> I did this consciously. Kernel is more strict, because there is no
> reasonable case when vmlinux BTF or BPF program's BTF can be empty (at
> least not that now we have FUNCs in BTF). But allowing libbpf to load
> empty BTF generically is helpful for bpftool, as one example, for
> inspection. If you do `bpftool btf dump` on empty BTF, it will just
> print nothing and you'll know that it's a valid (from BTF header
> perspective) BTF, just doesn't have any types (besides VOID). If we
> don't allow it, then we'll just get an error and then you'll have to
> do painful hex dumping and decoding to see what's wrong.

It is totally okay to allow empty btf in libbpf. I just want to check
if this btf is going to be loaded into the kernel, right before it is 
loading whether libbpf could check whether it is a non-module empty btf
or not, if it is, do not go to kernel.

> 
> In practice, no BPF program's BTF should be empty, but if it is, the
> kernel will rightfully stop you. I don't think it's a common enough
> case for libbpf to handle.

In general, libbpf should catch errors earlier if possible without going
to kernel. This way, we can have better error messages for user.
But I won't insist in this case as it is indeed really rare.

> 
>>
>>> -
>>>        if (meta_left < hdr->str_off + hdr->str_len) {
>>>                pr_debug("Invalid BTF total size:%u\n", btf->raw_size);
>>>                return -EINVAL;
>>>

  reply	other threads:[~2021-01-12  1:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-10  7:03 [PATCH bpf 1/2] bpf: allow empty module BTFs Andrii Nakryiko
2021-01-10  7:03 ` [PATCH bpf 2/2] libbpf: allow loading empty BTFs Andrii Nakryiko
2021-01-11 18:13   ` Yonghong Song
2021-01-11 20:51     ` Andrii Nakryiko
2021-01-12  1:15       ` Yonghong Song [this message]
2021-01-12  6:41         ` Andrii Nakryiko
2021-01-12 20:17           ` Daniel Borkmann
2021-01-12 20:26             ` Andrii Nakryiko
2021-01-11 18:08 ` [PATCH bpf 1/2] bpf: allow empty module BTFs Yonghong Song
2021-01-12 20:20 ` patchwork-bot+netdevbpf
2021-01-24 10:27   ` Christopher William Snowhill
2021-01-26  1:26     ` Andrii Nakryiko
2021-01-26  2:17       ` Christopher William Snowhill

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=31ebd16f-8218-1457-b4e2-3728ab147747@fb.com \
    --to=yhs@fb.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=chris@kode54.net \
    --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).