From: Paul Chaignon <paul.chaignon@orange.com>
To: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: bpf@vger.kernel.org,
Quentin Monnet <quentin.monnet@netronome.com>,
paul.chaignon@gmail.com, netdev@vger.kernel.org,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>, Andrii Nakryiko <andriin@fb.com>
Subject: Re: [PATCH bpf-next 1/3] bpftool: match several programs with same tag
Date: Fri, 13 Dec 2019 13:39:22 +0100 [thread overview]
Message-ID: <20191213123922.GA6538@Omicron> (raw)
In-Reply-To: <20191210123625.48ab21fa@cakuba.netronome.com>
On Tue, Dec 10, 2019 at 12:36:25PM -0800, Jakub Kicinski wrote:
> On Tue, 10 Dec 2019 17:06:25 +0100, Paul Chaignon wrote:
> > When several BPF programs have the same tag, bpftool matches only the
> > first (in ID order). This patch changes that behavior such that dump and
> > show commands return all matched programs. Commands that require a single
> > program (e.g., pin and attach) will error out if given a tag that matches
> > several. bpftool prog dump will also error out if file or visual are
> > given and several programs have the given tag.
> >
> > In the case of the dump command, a program header is added before each
> > dump only if the tag matches several programs; this patch doesn't change
> > the output if a single program matches.
>
> How does this work? Could you add examples to the commit message?
>
> This header idea doesn't seem correct, aren't id and other per-instance
> fields only printed once?
Sorry, that was unclear. What I call the header here is the first line
from the prog show output (in the case of plain output). So the output
when multiple programs match looks as follows. When a single program
matches, the first line (with the ID, type, name, tag and license) is
omitted.
$ ./bpftool prog dump xlated tag 6deef7357e7b4530
3: cgroup_skb tag 6deef7357e7b4530 gpl
0: (bf) r6 = r1
[...]
7: (95) exit
4: cgroup_skb tag 6deef7357e7b4530 gpl
0: (bf) r6 = r1
[...]
7: (95) exit
>
> > Signed-off-by: Paul Chaignon <paul.chaignon@orange.com>
>
> > - close(fd);
> > + if (nb_fds > 0) {
> > + tmp = realloc(fds, (nb_fds + 1) * sizeof(int));
> > + if (!tmp) {
> > + p_err("failed to realloc");
> > + goto err_close_fd;
> > + }
> > + fds = tmp;
>
> How does this work? the new array is never returned to the caller, and
> the caller will most likely access freed memory, no?
Oh, this is bad. Yes, fds should actually be "int **" and this line
should be "*fds = tmp;". I'll fix it in v2.
[...]
> > + close(fds[nb_fds]);
> > + }
> > + fd = -1;
> > + goto err_free;
> > + }
> > +
> > + fd = fds[0];
> > +err_free:
>
> nit: we tried to call the labels exit_xyz if the code is used on both
> error and success path, but maybe that pattern got lost over time.
Seems lost in prog.c but still valid across bpftool. I'll make the
change.
[...]
Paul
>
next prev parent reply other threads:[~2019-12-13 20:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-10 16:05 [PATCH bpf-next 0/3] bpftool: match programs and maps by names Paul Chaignon
2019-12-10 16:06 ` [PATCH bpf-next 1/3] bpftool: match several programs with same tag Paul Chaignon
2019-12-10 17:29 ` Quentin Monnet
2019-12-13 18:10 ` Paul Chaignon
2019-12-10 20:36 ` Jakub Kicinski
2019-12-13 12:39 ` Paul Chaignon [this message]
2019-12-10 16:06 ` [PATCH bpf-next 2/3] bpftool: match programs by name Paul Chaignon
2019-12-10 17:29 ` Quentin Monnet
2019-12-10 21:04 ` Jakub Kicinski
2019-12-13 12:40 ` Paul Chaignon
2019-12-13 17:56 ` Jakub Kicinski
2019-12-10 16:06 ` [PATCH bpf-next 3/3] bpftool: match maps " Paul Chaignon
2019-12-10 17:29 ` Quentin Monnet
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=20191213123922.GA6538@Omicron \
--to=paul.chaignon@orange.com \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jakub.kicinski@netronome.com \
--cc=kafai@fb.com \
--cc=netdev@vger.kernel.org \
--cc=paul.chaignon@gmail.com \
--cc=quentin.monnet@netronome.com \
--cc=songliubraving@fb.com \
--cc=yhs@fb.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.