On Thu, Feb 09, 2023 at 11:52:10AM -0800, Andrii Nakryiko wrote: > Do we need to add a new type to UAPI at all here? We can make this new > struct internal to kernel code (e.g. struct bpf_lpm_trie_key_kern) and > point out that it should match the layout of struct bpf_lpm_trie_key. > User-space can decide whether to use bpf_lpm_trie_key as-is, or if > just to ensure their custom struct has the same layout (I see some > internal users at Meta do just this, just make sure that they have > __u32 prefixlen as first member). The uses outside the kernel seemed numerous enough to justify a new UAPI struct (samples, selftests, etc). It also paves a single way forward when the userspace projects start using modern compiler options (e.g. systemd is usually pretty quick to adopt new features). > This whole union work-around seems like just extra cruft that we don't > really need in UAPI. The union is really only there so that possible uses of container_of() would be happy. But I did add a BUILD_BUG_ON() test for member offset equality, so a hard cast would be safe too. I'm happy to drop it if that's preferred? -- Kees Cook
