| Message ID | 20210926125605.1101605-1-memxor@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | BPF |
| Headers | show |
| Series | [bpf-next] samples: bpf: avoid name collision with kernel enum values | expand |
Kumar Kartikeya Dwivedi <memxor@gmail.com> writes: > In xdp_redirect_map_multi.bpf.c, on newer kernels samples compilation > fails when vmlinux.h is generated from a kernel supporting broadcast for > devmap. Hence, avoid naming collisions to prevent build failure. Hmm, shouldn't the sample just be getting the value from the kernel in the first place instead of re-defining it? -Toke
On Mon, Sep 27, 2021 at 06:07:30PM IST, Toke Høiland-Jørgensen wrote: > Kumar Kartikeya Dwivedi <memxor@gmail.com> writes: > > > In xdp_redirect_map_multi.bpf.c, on newer kernels samples compilation > > fails when vmlinux.h is generated from a kernel supporting broadcast for > > devmap. Hence, avoid naming collisions to prevent build failure. > > Hmm, shouldn't the sample just be getting the value from the kernel in > the first place instead of re-defining it? > True, but in general my assumption was that it could be built with a older kernel's vmlinux.h, but be ran on a newer one. If that's not strictly needed, I can just drop it. This can also be the case if you haven't built the kernel in the tree (just did a make headers_install), it then falls back to generating the vmlinux.h from the running kernel. > -Toke > -- Kartikeya
Kumar Kartikeya Dwivedi <memxor@gmail.com> writes: > On Mon, Sep 27, 2021 at 06:07:30PM IST, Toke Høiland-Jørgensen wrote: >> Kumar Kartikeya Dwivedi <memxor@gmail.com> writes: >> >> > In xdp_redirect_map_multi.bpf.c, on newer kernels samples compilation >> > fails when vmlinux.h is generated from a kernel supporting broadcast for >> > devmap. Hence, avoid naming collisions to prevent build failure. >> >> Hmm, shouldn't the sample just be getting the value from the kernel in >> the first place instead of re-defining it? >> > > True, but in general my assumption was that it could be built with a older > kernel's vmlinux.h, but be ran on a newer one. If that's not strictly needed, I > can just drop it. But the code is still making assumptions about the contents of vmlinux.h, isn't it? Like the size (and existence) of struct bpf_devmap_val. > This can also be the case if you haven't built the kernel in the tree > (just did a make headers_install), it then falls back to generating > the vmlinux.h from the running kernel. This seems a bit brittle. Given that the samples are distributed with the kernel sources, I would expect them to always correspond to the kernel version in the source tree they're in and not randomly break if the running kernel is different... -Toke
diff --git a/samples/bpf/xdp_redirect_map_multi.bpf.c b/samples/bpf/xdp_redirect_map_multi.bpf.c index 8f59d430cb64..c6361e70c829 100644 --- a/samples/bpf/xdp_redirect_map_multi.bpf.c +++ b/samples/bpf/xdp_redirect_map_multi.bpf.c @@ -6,8 +6,8 @@ #include "xdp_sample_shared.h" enum { - BPF_F_BROADCAST = (1ULL << 3), - BPF_F_EXCLUDE_INGRESS = (1ULL << 4), + __BPF_F_BROADCAST = (1ULL << 3), + __BPF_F_EXCLUDE_INGRESS = (1ULL << 4), }; struct { @@ -43,7 +43,8 @@ static int xdp_redirect_map(struct xdp_md *ctx, void *forward_map) NO_TEAR_INC(rec->processed); return bpf_redirect_map(forward_map, 0, - BPF_F_BROADCAST | BPF_F_EXCLUDE_INGRESS); + __BPF_F_BROADCAST | + __BPF_F_EXCLUDE_INGRESS); } SEC("xdp")
In xdp_redirect_map_multi.bpf.c, on newer kernels samples compilation fails when vmlinux.h is generated from a kernel supporting broadcast for devmap. Hence, avoid naming collisions to prevent build failure. Fixes: a29b3ca17ee6 (samples: bpf: Convert xdp_redirect_map_multi_kern.o to XDP samples helper) Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> --- samples/bpf/xdp_redirect_map_multi.bpf.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) -- 2.33.0