From: Stanislav Fomichev <sdf@fomichev.me>
To: Andrii Nakryiko <andriin@fb.com>
Cc: andrii.nakryiko@gmail.com, netdev@vger.kernel.org,
bpf@vger.kernel.org, ast@fb.com, daniel@iogearbox.net,
kernel-team@fb.com
Subject: Re: [PATCH v2 bpf-next 6/9] libbpf: use negative fd to specify missing BTF
Date: Tue, 2 Jul 2019 16:18:26 -0700 [thread overview]
Message-ID: <20190702231826.GL6757@mini-arch> (raw)
In-Reply-To: <20190702225733.GK6757@mini-arch>
On 07/02, Stanislav Fomichev wrote:
> On 05/29, Andrii Nakryiko wrote:
> > 0 is a valid FD, so it's better to initialize it to -1, as is done in
> > other places. Also, technically, BTF type ID 0 is valid (it's a VOID
> > type), so it's more reliable to check btf_fd, instead of
> > btf_key_type_id, to determine if there is any BTF associated with a map.
> >
> > Acked-by: Song Liu <songliubraving@fb.com>
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> > tools/lib/bpf/libbpf.c | 13 +++++++------
> > 1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > index c972fa10271f..a27a0351e595 100644
> > --- a/tools/lib/bpf/libbpf.c
> > +++ b/tools/lib/bpf/libbpf.c
> > @@ -1751,7 +1751,7 @@ bpf_object__create_maps(struct bpf_object *obj)
> > create_attr.key_size = def->key_size;
> > create_attr.value_size = def->value_size;
> > create_attr.max_entries = def->max_entries;
> > - create_attr.btf_fd = 0;
> > + create_attr.btf_fd = -1;
> > create_attr.btf_key_type_id = 0;
> > create_attr.btf_value_type_id = 0;
> > if (bpf_map_type__is_map_in_map(def->type) &&
> > @@ -1765,11 +1765,11 @@ bpf_object__create_maps(struct bpf_object *obj)
> > }
> >
> > *pfd = bpf_create_map_xattr(&create_attr);
> > - if (*pfd < 0 && create_attr.btf_key_type_id) {
> > + if (*pfd < 0 && create_attr.btf_fd >= 0) {
> > cp = libbpf_strerror_r(errno, errmsg, sizeof(errmsg));
> > pr_warning("Error in bpf_create_map_xattr(%s):%s(%d). Retrying without BTF.\n",
> > map->name, cp, errno);
> > - create_attr.btf_fd = 0;
> > + create_attr.btf_fd = -1;
> This breaks libbpf compatibility with the older kernels. If the kernel
> doesn't know about btf_fd and we set it to -1, then CHECK_ATTR
> fails :-(
>
> Any objections to converting BTF retries to bpf_capabilities and then
> knowingly passing bft_fd==0 or proper fd?
Oh, nevermind, it looks like you fixed it already in e55d54f43d3f.
> > create_attr.btf_key_type_id = 0;
> > create_attr.btf_value_type_id = 0;
> > map->btf_key_type_id = 0;
> > @@ -2053,6 +2053,9 @@ load_program(struct bpf_program *prog, struct bpf_insn *insns, int insns_cnt,
> > char *log_buf;
> > int ret;
> >
> > + if (!insns || !insns_cnt)
> > + return -EINVAL;
> > +
> > memset(&load_attr, 0, sizeof(struct bpf_load_program_attr));
> > load_attr.prog_type = prog->type;
> > load_attr.expected_attach_type = prog->expected_attach_type;
> > @@ -2063,7 +2066,7 @@ load_program(struct bpf_program *prog, struct bpf_insn *insns, int insns_cnt,
> > load_attr.license = license;
> > load_attr.kern_version = kern_version;
> > load_attr.prog_ifindex = prog->prog_ifindex;
> > - load_attr.prog_btf_fd = prog->btf_fd >= 0 ? prog->btf_fd : 0;
> > + load_attr.prog_btf_fd = prog->btf_fd;
> > load_attr.func_info = prog->func_info;
> > load_attr.func_info_rec_size = prog->func_info_rec_size;
> > load_attr.func_info_cnt = prog->func_info_cnt;
> > @@ -2072,8 +2075,6 @@ load_program(struct bpf_program *prog, struct bpf_insn *insns, int insns_cnt,
> > load_attr.line_info_cnt = prog->line_info_cnt;
> > load_attr.log_level = prog->log_level;
> > load_attr.prog_flags = prog->prog_flags;
> > - if (!load_attr.insns || !load_attr.insns_cnt)
> > - return -EINVAL;
> >
> > retry_load:
> > log_buf = malloc(log_buf_size);
> > --
> > 2.17.1
> >
next prev parent reply other threads:[~2019-07-03 1:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-29 17:36 [PATCH v2 bpf-next 0/9] libbpf random fixes Andrii Nakryiko
2019-05-29 17:36 ` [PATCH v2 bpf-next 1/9] libbpf: fix detection of corrupted BPF instructions section Andrii Nakryiko
2019-05-29 18:01 ` Song Liu
2019-05-29 17:36 ` [PATCH v2 bpf-next 2/9] libbpf: preserve errno before calling into user callback Andrii Nakryiko
2019-05-29 17:36 ` [PATCH v2 bpf-next 3/9] libbpf: simplify endianness check Andrii Nakryiko
2019-05-29 17:36 ` [PATCH v2 bpf-next 4/9] libbpf: check map name retrieved from ELF Andrii Nakryiko
2019-05-29 17:36 ` [PATCH v2 bpf-next 5/9] libbpf: fix error code returned on corrupted ELF Andrii Nakryiko
2019-05-29 17:36 ` [PATCH v2 bpf-next 6/9] libbpf: use negative fd to specify missing BTF Andrii Nakryiko
2019-07-02 22:57 ` Stanislav Fomichev
2019-07-02 23:18 ` Stanislav Fomichev [this message]
2019-05-29 17:36 ` [PATCH v2 bpf-next 7/9] libbpf: simplify two pieces of logic Andrii Nakryiko
2019-05-29 17:36 ` [PATCH v2 bpf-next 8/9] libbpf: typo and formatting fixes Andrii Nakryiko
2019-05-29 17:36 ` [PATCH v2 bpf-next 9/9] libbpf: reduce unnecessary line wrapping Andrii Nakryiko
2019-05-29 23:26 ` [PATCH v2 bpf-next 0/9] libbpf random fixes Daniel Borkmann
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=20190702231826.GL6757@mini-arch \
--to=sdf@fomichev.me \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--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).