[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87mud5qosd.fsf@toke.dk>
Date: Sat, 09 Nov 2019 12:20:34 +0100
From: Toke Høiland-Jørgensen <toke@...hat.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Daniel Borkmann <daniel@...earbox.net>,
Alexei Starovoitov <ast@...nel.org>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
Jesper Dangaard Brouer <brouer@...hat.com>,
David Miller <davem@...emloft.net>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next v3 5/6] libbpf: Add bpf_get_link_xdp_info() function to get more XDP information
Andrii Nakryiko <andrii.nakryiko@...il.com> writes:
> On Fri, Nov 8, 2019 at 4:01 PM Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>>
>> From: Toke Høiland-Jørgensen <toke@...hat.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@...emloft.net>
>> Acked-by: Song Liu <songliubraving@...com>
>> Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.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?
-Toke
Powered by blists - more mailing lists