Stanislav Fomichev <sdf@xxxxxxxxxx> writes: > On Tue, Nov 15, 2022 at 7:54 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: >> >> Stanislav Fomichev <sdf@xxxxxxxxxx> writes: >> >> > - drop __randomize_layout >> > >> > Not sure it's possible to sanely expose it via UAPI. Because every >> > .o potentially gets its own randomized layout, test_progs >> > refuses to link. >> >> So this won't work if the struct is in a kernel-supplied UAPI header >> (which would include the __randomize_layout tag). But if it's *not* in a >> UAPI header it should still be included in a stable form (i.e., without >> the randomize tag) in vmlinux.h, right? Which would be the point: >> consumers would be forced to read it from there and do CO-RE on it... > > So you're suggesting something like the following in the uapi header? > > #ifndef __KERNEL__ > #define __randomize_layout > #endif > > ? I actually just meant "don't put struct xdp_metadata in an UAPI header file at all". However, I can see how that complicates having the skb_metadata pointer in struct xdp_md, so if the above works, that's fine with me as well :) > Let me try to add some padding arguments to xdp_skb_metadata plus the > above to see how it goes. Cool! -Toke
