bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Chaignon <paul.chaignon@orange.com>
To: Quentin Monnet <quentin.monnet@netronome.com>
Cc: bpf@vger.kernel.org, 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 19:10:40 +0100	[thread overview]
Message-ID: <20191213181040.GA6096@Omicron> (raw)
In-Reply-To: <99f35770-9a3f-2135-a9a6-34d931b1ae1e@netronome.com>

On Tue, Dec 10, 2019 at 05:29:18PM +0000, Quentin Monnet wrote:
> Hi Paul,
> 
> 2019-12-10 17:06 UTC+0100 ~ Paul Chaignon <paul.chaignon@orange.com>
> > 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.
> > 
> > Signed-off-by: Paul Chaignon <paul.chaignon@orange.com>
> > ---
> >  .../bpftool/Documentation/bpftool-prog.rst    |  16 +-
> >  tools/bpf/bpftool/prog.c                      | 371 ++++++++++++------
> >  2 files changed, 272 insertions(+), 115 deletions(-)
> > 

[...]

> > @@ -351,21 +421,43 @@ static int show_prog(int fd)
> >  
> >  static int do_show(int argc, char **argv)
> >  {
> > +	int fd, nb_fds, i;
> > +	int *fds = NULL;
> >  	__u32 id = 0;
> >  	int err;
> > -	int fd;
> >  
> >  	if (show_pinned)
> >  		build_pinned_obj_table(&prog_table, BPF_OBJ_PROG);
> >  
> >  	if (argc == 2) {
> > -		fd = prog_parse_fd(&argc, &argv);
> > -		if (fd < 0)
> > +		fds = malloc(sizeof(int));
> > +		if (!fds) {
> > +			p_err("mem alloc failed");
> >  			return -1;
> > +		}
> > +		nb_fds = prog_parse_fds(&argc, &argv, fds);
> > +		if (nb_fds < 1)
> > +			goto err_free;
> >  
> > -		err = show_prog(fd);
> > -		close(fd);
> > -		return err;
> > +		if (json_output && nb_fds > 1)
> > +			jsonw_start_array(json_wtr);	/* root array */
> > +		for (i = 0; i < nb_fds; i++) {
> > +			err = show_prog(fds[i]);
> > +			close(fds[i]);
> > +			if (err) {
> > +				for (i++; i < nb_fds; i++)
> > +					close(fds[i]);
> > +				goto err_free;
> 
> Alternatively, we could keep trying to list the remaining programs. For
> example, if the system has a long list of BPF programs running and one
> of them is removed while printing the list, we would still have the rest
> of the list.

As discussed off the list, since the kernel keeps a refcount for programs,
a program won't be removed while printing the list, not as long as we hold
an fd to it.  Unless there's another common case of failure, I'm going to
keep the current behavior in the v2 and break out of the loop on errors
(though, with the appropriate JSON array closing).

> 
> If we went this way, maybe just set err to non-zero if no program at all
> could be printed?
> 
> > +			}
> > +		}
> > +		if (json_output && nb_fds > 1)
> > +			jsonw_end_array(json_wtr);	/* root array */
> > +
> > +		return 0;
> > +
> > +err_free:
> > +		free(fds);
> > +		return -1;
> >  	}
> >  
> >  	if (argc)

  reply	other threads:[~2019-12-13 20:40 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 [this message]
2019-12-10 20:36   ` Jakub Kicinski
2019-12-13 12:39     ` Paul Chaignon
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=20191213181040.GA6096@Omicron \
    --to=paul.chaignon@orange.com \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --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 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).