From: John Fastabend <john.fastabend@gmail.com>
To: John Fastabend <john.fastabend@gmail.com>,
Stanislav Fomichev <sdf@google.com>,
netdev@vger.kernel.org, bpf@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
Stanislav Fomichev <sdf@google.com>
Subject: RE: [PATCH bpf-next 2/3] bpftool: don't append / to the progtype
Date: Fri, 22 Oct 2021 10:26:00 -0700 [thread overview]
Message-ID: <6172f428e4174_86bab20824@john-XPS-13-9370.notmuch> (raw)
In-Reply-To: <6172ef4180b84_840632087a@john-XPS-13-9370.notmuch>
John Fastabend wrote:
> Stanislav Fomichev wrote:
> > Otherwise, attaching with bpftool doesn't work with strict section names.
> >
> > Also, switch to libbpf strict mode to use the latest conventions
> > (note, I don't think we have any cli api guarantees?).
> >
> > Signed-off-by: Stanislav Fomichev <sdf@google.com>
> > ---
> > tools/bpf/bpftool/main.c | 4 ++++
> > tools/bpf/bpftool/prog.c | 15 +--------------
> > 2 files changed, 5 insertions(+), 14 deletions(-)
> >
> > diff --git a/tools/bpf/bpftool/main.c b/tools/bpf/bpftool/main.c
> > index 02eaaf065f65..8223bac1e401 100644
> > --- a/tools/bpf/bpftool/main.c
> > +++ b/tools/bpf/bpftool/main.c
> > @@ -409,6 +409,10 @@ int main(int argc, char **argv)
> > block_mount = false;
> > bin_name = argv[0];
> >
> > + ret = libbpf_set_strict_mode(LIBBPF_STRICT_ALL);
> > + if (ret)
> > + p_err("failed to enable libbpf strict mode: %d", ret);
> > +
>
> Would it better to just warn? Seems like this shouldn't be fatal from
> bpftool side?
>
> Also this is a potentially breaking change correct? Programs that _did_
> work in the unstrict might suddently fail in the strict mode? If this
> is the case whats the versioning plan? We don't want to leak these
> type of changes across multiple versions, idealy we have a hard
> break and bump the version.
>
> I didn't catch a cover letter on the series. A small
> note about versioning and upgrading bpftool would be helpful.
>
>
> > hash_init(prog_table.table);
> > hash_init(map_table.table);
> > hash_init(link_table.table);
> > diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
> > index 277d51c4c5d9..17505dc1243e 100644
> > --- a/tools/bpf/bpftool/prog.c
> > +++ b/tools/bpf/bpftool/prog.c
> > @@ -1396,8 +1396,6 @@ static int load_with_options(int argc, char **argv, bool first_prog_only)
> >
> > while (argc) {
> > if (is_prefix(*argv, "type")) {
> > - char *type;
> > -
> > NEXT_ARG();
> >
> > if (common_prog_type != BPF_PROG_TYPE_UNSPEC) {
> > @@ -1407,19 +1405,8 @@ static int load_with_options(int argc, char **argv, bool first_prog_only)
> > if (!REQ_ARGS(1))
> > goto err_free_reuse_maps;
> >
> > - /* Put a '/' at the end of type to appease libbpf */
> > - type = malloc(strlen(*argv) + 2);
> > - if (!type) {
> > - p_err("mem alloc failed");
> > - goto err_free_reuse_maps;
> > - }
> > - *type = 0;
> > - strcat(type, *argv);
> > - strcat(type, "/");
> > -
> > - err = get_prog_type_by_name(type, &common_prog_type,
> > + err = get_prog_type_by_name(*argv, &common_prog_type,
> > &expected_attach_type);
> > - free(type);
> > if (err < 0)
> > goto err_free_reuse_maps;
>
> This wont potentially break existing programs correct? It looks like
> just adding a '/' should be fine.
>
> Thanks,
> John
Oops wrong version of the patch. I'll reply in the more recent one.
next prev parent reply other threads:[~2021-10-22 17:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-11 15:56 [PATCH bpf-next 1/3] libbpf: use func name when pinning programs with LIBBPF_STRICT_SEC_NAME Stanislav Fomichev
2021-10-11 15:56 ` [PATCH bpf-next 2/3] bpftool: don't append / to the progtype Stanislav Fomichev
2021-10-22 17:05 ` John Fastabend
2021-10-22 17:26 ` John Fastabend [this message]
2021-10-25 15:58 ` Stanislav Fomichev
2021-10-26 4:27 ` Andrii Nakryiko
2021-10-26 15:46 ` Stanislav Fomichev
2021-10-26 17:03 ` Andrii Nakryiko
2021-10-11 15:56 ` [PATCH bpf-next 3/3] selftests/bpf: fix flow dissector tests Stanislav Fomichev
2021-10-12 4:07 ` [PATCH bpf-next 1/3] libbpf: use func name when pinning programs with LIBBPF_STRICT_SEC_NAME Andrii Nakryiko
2021-10-12 4:11 ` 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=6172f428e4174_86bab20824@john-XPS-13-9370.notmuch \
--to=john.fastabend@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=netdev@vger.kernel.org \
--cc=sdf@google.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).