From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: David Ahern <dsahern@gmail.com>,
bpf@vger.kernel.org, netdev@vger.kernel.org,
Daniel Borkmann <borkmann@iogearbox.net>,
Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Lorenzo Bianconi <lorenzo@kernel.org>,
brouer@redhat.com
Subject: Re: [PATCH bpf 0/3] bpf: avoid using/returning file descriptor value zero
Date: Tue, 9 Jun 2020 11:55:13 +0200 [thread overview]
Message-ID: <20200609115513.2422b53a@carbon> (raw)
In-Reply-To: <20200609013410.5ktyuzlqu5xpbp4a@ast-mbp.dhcp.thefacebook.com>
On Mon, 8 Jun 2020 18:34:10 -0700
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> On Mon, Jun 08, 2020 at 06:51:12PM +0200, Jesper Dangaard Brouer wrote:
> > Make it easier to handle UAPI/kABI extensions by avoid BPF using/returning
> > file descriptor value zero. Use this in recent devmap extension to keep
> > older applications compatible with newer kernels.
> >
> > For special type maps (e.g. devmap and cpumap) the map-value data-layout is
> > a configuration interface. This is a kernel Application Binary Interface
> > (kABI) that can only be tail extended. Thus, new members (and thus features)
> > can only be added to the end of this structure, and the kernel uses the
> > map->value_size from userspace to determine feature set 'version'.
>
> please drop these kabi references. As far as I know kabi is a redhat invention
> and I'm not even sure what exactly it means.
> 'struct bpf_devmap_val' is uapi. No need to invent new names for existing concept.
Sure I can call it UAPI.
I was alluding to the difference between API and ABI, but it doesn't matter.
For the record, Red Hat didn't invent ABI (Application Binary Interface):
https://en.wikipedia.org/wiki/Application_binary_interface
> > The recent extension of devmap with a bpf_prog.fd requires end-user to
> > supply the file-descriptor value minus-1 to communicate that the features
> > isn't used. This isn't compatible with the described kABI extension model.
>
> non-zero prog_fd requirement exists already in bpf syscall. It's not recent.
> So I don't think patch 1 is appropriate at this point. Certainly not
> for bpf tree. We can argue about it usefulness when bpf-next reopens.
> For now I think patches 2 and 3 are good to go.
Great.
> Don't delete 'enum sk_action' in patch 2 though.
Sorry, yes, that was a mistake.
> The rest looks good to me.
Thanks!
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2020-06-09 9:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-08 16:51 [PATCH bpf 0/3] bpf: avoid using/returning file descriptor value zero Jesper Dangaard Brouer
2020-06-08 16:51 ` [PATCH bpf 1/3] bpf: syscall to start at file-descriptor 1 Jesper Dangaard Brouer
2020-06-08 18:28 ` Toke Høiland-Jørgensen
2020-06-08 18:36 ` Andrii Nakryiko
2020-06-08 19:44 ` Jesper Dangaard Brouer
2020-06-08 20:05 ` Andrii Nakryiko
2020-06-08 19:00 ` kernel test robot
2020-06-08 19:00 ` kernel test robot
2020-06-08 19:55 ` kernel test robot
2020-06-08 19:55 ` kernel test robot
2020-06-08 19:55 ` [RFC PATCH] bpf: bpf_anon_inode_getfd() can be static kernel test robot
2020-06-08 19:55 ` kernel test robot
2020-06-08 20:39 ` [PATCH bpf 1/3] bpf: syscall to start at file-descriptor 1 kernel test robot
2020-06-08 20:39 ` kernel test robot
2020-06-08 20:42 ` kernel test robot
2020-06-08 20:42 ` kernel test robot
2020-06-08 16:51 ` [PATCH bpf 2/3] bpf: devmap adjust uapi for attach bpf program Jesper Dangaard Brouer
2020-06-08 18:30 ` Toke Høiland-Jørgensen
2020-06-08 16:51 ` [PATCH bpf 3/3] bpf: selftests and tools use struct bpf_devmap_val from uapi Jesper Dangaard Brouer
2020-06-09 1:34 ` [PATCH bpf 0/3] bpf: avoid using/returning file descriptor value zero Alexei Starovoitov
2020-06-09 9:55 ` Jesper Dangaard Brouer [this message]
2020-06-09 13:31 ` [PATCH bpf V2 0/2] bpf: adjust uapi for devmap prior to kernel release Jesper Dangaard Brouer
2020-06-09 13:31 ` [PATCH bpf V2 1/2] bpf: devmap adjust uapi for attach bpf program Jesper Dangaard Brouer
2020-06-09 13:47 ` David Ahern
2020-06-09 15:12 ` Jesper Dangaard Brouer
2020-06-09 13:31 ` [PATCH bpf V2 2/2] bpf: selftests and tools use struct bpf_devmap_val from uapi Jesper Dangaard Brouer
2020-06-09 19:03 ` [PATCH bpf V2 0/2] bpf: adjust uapi for devmap prior to kernel release Alexei Starovoitov
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=20200609115513.2422b53a@carbon \
--to=brouer@redhat.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=borkmann@iogearbox.net \
--cc=bpf@vger.kernel.org \
--cc=dsahern@gmail.com \
--cc=lorenzo@kernel.org \
--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 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.