Re: [PATCH bpf-next v3 5/6] libbpf: Add bpf_get_link_xdp_info() function to get more XDP information

From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <ast@kernel.org>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	David Miller <davem@davemloft.net>,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next v3 5/6] libbpf: Add bpf_get_link_xdp_info() function to get more XDP information
Date: Sat, 9 Nov 2019 11:10:38 -0800	[thread overview]
Message-ID: <CAEf4BzbRGryvV+wYzOUECN3ceTZaGObtQQ3dQuaJJ4tTRbyyzw@mail.gmail.com> (raw)
In-Reply-To: <87mud5qosd.fsf@toke.dk>

On Sat, Nov 9, 2019 at 3:20 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
>
> > On Fri, Nov 8, 2019 at 4:01 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
> >>
> >> From: Toke Høiland-Jørgensen <toke@redhat.com>
> >>
> >> Currently, libbpf only provides a function to get a single ID for the XDP
> >> program attached to the interface. However, it can be useful to get the
> >> full set of program IDs attached, along with the attachment mode, in one
> >> go. Add a new getter function to support this, using an extendible
> >> structure to carry the information. Express the old bpf_get_link_id()
> >> function in terms of the new function.
> >>
> >> Acked-by: David S. Miller <davem@davemloft.net>
> >> Acked-by: Song Liu <songliubraving@fb.com>
> >> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
> >> ---
> >>  tools/lib/bpf/libbpf.h   |   10 ++++++
> >>  tools/lib/bpf/libbpf.map |    1 +
> >>  tools/lib/bpf/netlink.c  |   82 ++++++++++++++++++++++++++++++----------------
> >>  3 files changed, 65 insertions(+), 28 deletions(-)
> >>
> >
> > [...]
> >
> >>
> >> -int bpf_get_link_xdp_id(int ifindex, __u32 *prog_id, __u32 flags)
> >> +int bpf_get_link_xdp_info(int ifindex, struct xdp_link_info *info,
> >> +                         size_t info_size, __u32 flags)
> >>  {
> >>         struct xdp_id_md xdp_id = {};
> >>         int sock, ret;
> >>         __u32 nl_pid;
> >>         __u32 mask;
> >>
> >> -       if (flags & ~XDP_FLAGS_MASK)
> >> +       if (flags & ~XDP_FLAGS_MASK || info_size < sizeof(*info))
> >>                 return -EINVAL;
> >
> > Well, now it's backwards-incompatible: older program passes smaller
> > (but previously perfectly valid) sizeof(struct xdp_link_info) to newer
> > version of libbpf. This has to go both ways: smaller struct should be
> > supported as long as program doesn't request (using flags) something,
> > that can't be put into allowed space.
>
> But there's nothing to be backwards-compatible with? I get that *when*
> we extend the size of xdp_link_info, we should still accept the old,
> smaller size. But in this case that cannot happen as we're only just
> introducing this now?

This seems like a shifting burden to next person that will have to
extend this, but ok, fine by me.

>
> -Toke