bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Jesper Dangaard Brouer <brouer@redhat.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>
Subject: Re: [PATCH bpf V2 0/2] bpf: adjust uapi for devmap prior to kernel release
Date: Tue, 9 Jun 2020 12:03:12 -0700	[thread overview]
Message-ID: <20200609190312.cymwvcbxdnrelatx@ast-mbp.dhcp.thefacebook.com> (raw)
In-Reply-To: <159170947966.2102545.14401752480810420709.stgit@firesoul>

On Tue, Jun 09, 2020 at 03:31:41PM +0200, Jesper Dangaard Brouer wrote:
> For special type maps (e.g. devmap and cpumap) the map-value data-layout is
> a configuration interface. This is uapi 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'.
> 
> For this kind of uapi to be extensible and backward compatible, is it common
> that new members/fields (that represent a new feature) in the struct are
> initialized as zero, which indicate that the feature isn't used. This makes
> it possible to write userspace applications that are unaware of new kernel
> features, but just include latest uapi headers, zero-init struct and
> populate features it knows about.
> 
> 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.

Applied to bpf tree without this cover letter, because I don't want
folks to read above and start using kabi terminology liks this.
I've never seen a definition of kabi. I've heard redhat has something, but
I don't know what it is and really not interested to find out.
Studying amd64 psABI, sparc psABI, gABI was enough of time sink.
When folks use ABI they really mean binary. 
Old binaries that use devmap_val will work as-is with newer kernel.
There is no binary breakage due to devmap_val.
Whereas what you describe above is what will happen if something gets
recompiled. It's an API quirk. And arguable not an UAPI breakage.
UAPI structs have to initialized.
There is a struct and there is initializer for it.
Like if you did 'spinlock_t lock;' and it got broken with new kernel
it's programmers fault. It's not uapi and certainly not abi issue.
DEFINE_SPINLOCK() should have been used.
Same thing with user space.
'struct bpf_devmap_val' would be ok from uapi pov even with -1.
It's just much more convenient to have zero init. Less error prone, etc.

      parent reply	other threads:[~2020-06-09 19:03 UTC|newest]

Thread overview: 21+ 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: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 20:42   ` [PATCH bpf 1/3] bpf: syscall to start at file-descriptor 1 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
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     ` Alexei Starovoitov [this message]

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=20200609190312.cymwvcbxdnrelatx@ast-mbp.dhcp.thefacebook.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=borkmann@iogearbox.net \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --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 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).