On Fri, Apr 5, 2024 at 12:38 PM Stephen Hemminger <stephen@xxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 5 Apr 2024 10:31:46 -0700 > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > On Thu, Apr 4, 2024 at 5:53 PM Stephen Hemminger > > <stephen@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Thu, 4 Apr 2024 14:45:04 -0700 > > > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > > > > > This is a known issue as currently vmlinux.h does not support macros. > > > > > > There are some efforts by Edward Zingerman to support this but this has > > > > > > not done yet. At the same time, you could have a trivial header file > > > > > > like > > > > > > https://github.com/torvalds/linux/blob/master/tools/testing/selftests/bpf/progs/bpf_tracing_net.h > > > > > > to be used for bpf program and then your bpf program with vmlinux.h can > > > > > > have much easier CORE support. > > > > > > > > > > > > > > > That is an example of header surgery which I would rather avoid having to carry > > > > > as long term technical debt baggage. > > > > > > > > > > > > > What's your ultimate goal? As Yonghong said, vmlinux.h is not > > > > compatible with other headers. So you have to pick either using > > > > vmlinux.h as a base + adding missing #define's (because those are not > > > > recorded in types, so can't be put into vmlinux.h), or not use > > > > vmlinux.h, use linux UAPI/internal headers and then use explicit CO-RE > > > > helpers/attributes to make your application CO-RE-relocatable. > > > > > > > > It's not clear from your original email why exactly you wanted to > > > > switch to vmlinux.h in the first place. > > > > > > Some backstory. There is not an existing TC filter for this, so the > > > original developer had the idea of using BPF to do it. > > > > > > The program is a small BPF program to implement a TC filter that looks at > > > SKB and does mapping to queue based on L3 (or L3/L4) header. So not heavily dependent > > > on kernel data structure, but sk_buff is not necessarily stable; actual layout > > > depends on kernel config. > > > > > > > If it's only a few fields from sk_buff that you need, you can define > > your own minimal sk_buff definition with > > __attribute__((preserve_access_index)) added to it. You don't have to > > declare fields in the right order, just make sure that field types > > match. E.g., something like: > > > > struct sk_buff { > > unsigned char *head; > > unsigned char *data; > > struct sock *sock; > > } __attribute__((preserve_access_index)); > > > > You can call it `struct sk_buff___mine` if you already include > > sk_buff, to avoid the conflict. Libbpf will still understand that it > > should match it to struct sk_buff in the kernel. > > > > Alternatively, you can just use BPF_CORE_READ() macro on types you get > > from kernel headers, even if they don't have that > > preserve_access_index attribute. > > > > Or, you can just use __builtin_preserve_access_index(&skb->len) to > > access sk_buff's fields in CO-RE-relocatable way. > > > > Or, you can have entire block within which all fields accesses will be > > CO-RE-relocatable: > > > > int len; > > > > __builtin_preserve_access_index(({ > > len = skb->len; > > /* other skb accesses here as well */ > > })); > > > > Many ways to have bolted on CO-RE even without vmlinux.h. vmlinux.h is > > convenient (apart from lack of #defines, but that's an orthogonal > > problem), but by no means required for BPF CO-RE. > > > > > The skbuff pointer is passed to the TC program. So BPF_CORE_READ doesn't > make sense here. The biggest concern is that kernel config of the build > machine may not match the kernel config of the eventual target, and some > of the fields of the sk_buff are hidden based on #ifdef and may change. And everything else I wrote?.. Regardless, I think at this point if you want to get help, you probably should provide the source code.
