Re: [PATCH bpf-next v1 0/3] Avoid typedef size mismatches in skeletons

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Thu, Feb 10, 2022 at 3:59 PM Delyan Kratunov <delyank@fb.com> wrote:
>
> On Thu, 2022-02-10 at 15:14 -0800, Alexei Starovoitov wrote:
> > So adding
> > _Static_assert(sizeof(type_in_skel) == const_size_from_kernel);
> > to skel.h would force users to pick types that are the same
> > both in bpf prog and in corresponding user space part.
>
> I'm not sure users have this much control over the definition of the types in
> their program though. If a kernel and uapi typedef differ in size, this approach
> would force the user to use kernel types for the entire program.
>
> If, for example, pid_t is a different size in glibc and the kernel, it would
> force you out of using any glibc functions taking pid_t (and potentially all of
> glibc depending on how entangled the headers are).

pid_t is a great example, since its meaning is different
in kernel and in user space.
One is thread and another is process.

static_assert will catch such issues and will force
users to pick u64 and think through the type
conversions. In kernel from pid_t -> u64 in bpf prog,
and in user space pid_t -> u64 in skel.
That would be an explicit action by users that hopefully
make them think about the differences in size and semantics.

> By normalizing to stdint types, we're saying that the contract represented by
> the skel does not operate with either uapi or kernel types and it's up to you to
> ensure you use the right one (or mix and match, if you can). It feels
> fundamentally more permissive to different types of situations than forcing the
> skel user to only use kernel types or refactor their program to isolate the
> kernel type leakage to only the compilation unit using the skel.

static_assert will force users to use compatible types, not kernel types.