Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > On Tue, Nov 15, 2022 at 10:38 AM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote: >> >> 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 >> > > 1. > __randomize_layout in uapi header makes no sense. I agree, which is why I wanted it to be only in vmlinux.h... > 2. > It's supported by gcc plugin and afaik that plugin is broken > vs debug info, so dwarf is broken, hence BTF is broken too, > and CO-RE doesn't work on kernels compiled with that gcc plugin. ...however this one seems a deal breaker. Ah well, too bad, seemed like a neat trick to enforce CO-RE :( -Toke
