On Tue, Oct 1, 2019 at 9:48 AM Jesper Dangaard Brouer <brouer@xxxxxxxxxx> wrote:
>
> On Mon, 30 Sep 2019 09:42:39 -0700
> Andrii Nakryiko <andriin@xxxxxx> wrote:
>
> > diff --git a/tools/lib/bpf/libbpf_internal.h b/tools/lib/bpf/libbpf_internal.h
> > index 2e83a34f8c79..1cf2cf8d80f3 100644
> > --- a/tools/lib/bpf/libbpf_internal.h
> > +++ b/tools/lib/bpf/libbpf_internal.h
> > @@ -47,6 +47,12 @@ do { \
> > #define pr_info(fmt, ...) __pr(LIBBPF_INFO, fmt, ##__VA_ARGS__)
> > #define pr_debug(fmt, ...) __pr(LIBBPF_DEBUG, fmt, ##__VA_ARGS__)
> >
> > +#define OPTS_VALID(opts) (!(opts) || (opts)->sz >= sizeof((opts)->sz))
>
> Do be aware that C sizeof() will include the padding the compiler does.
> Thus, when extending a struct (e.g. in a newer version) the size
> (sizeof) might not actually increase (if compiler padding room exist).
Yes, that's a very good point, thanks for bringing this up!
I was debating whether OPTS_VALID should validate (similar to kernel)
that all the bytes between user's struct size and our
latest-and-greatest struct definition size are set to zero. But this
padding issue just proves it has to be done always.
And it also shows that using struct initialization to zero (or using
macro with struct field initializers) is almost a must to avoid issue
like this. On libbpf side I think we can just provide helpful message
to user, otherwise it might be hair-pulling to figure out what's
wrong.
>
> > +#define OPTS_HAS(opts, field) \
> > + ((opts) && opts->sz >= offsetofend(typeof(*(opts)), field))
> > +#define OPTS_GET(opts, field, fallback_value) \
> > + (OPTS_HAS(opts, field) ? (opts)->field : fallback_value)
>
> I do think, that these two "accessor" defines address the padding issue
> I described above.
>
> p.s. I appreciate that you are working on this, and generally like the idea.
Thanks!
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
