strace for m68k bpf_prog_info mismatch

[Dmitry V. Levin]

Hi Geert,

On Fri, May 03, 2019 at 09:04:17AM +0200, Geert Uytterhoeven wrote:
> Hi Baruch,
> 
> On Fri, May 3, 2019 at 6:06 AM Baruch Siach <baruch at tkos.co.il> wrote:
> > strace 5.0 fails to build for m86k/5208 with the Buildroot generated
> > toolchain:
> >
> > In file included from bpf_attr_check.c:6:0:
> > static_assert.h:20:25: error: static assertion failed: "bpf_prog_info_struct.nr_jited_ksyms offset mismatch"
> >  #  define static_assert _Static_assert
> >                          ^
> > bpf_attr_check.c:913:2: note: in expansion of macro ‘static_assert’
> >   static_assert(offsetof(struct bpf_prog_info_struct, nr_jited_ksyms) == offsetof(struct bpf_prog_info, nr_jited_ksyms),
> >   ^~~~~~~~~~~~~
> >
> > The direct cause is a difference in the hole after the gpl_compatible
> > field. Here is pahole output for the kernel struct (from v4.19):
> >
> > struct bpf_prog_info {
> >         ...
> >         __u32                      ifindex;              /*    80     4 */
> >         __u32                      gpl_compatible:1;     /*    84: 0  4 */
> >
> >         /* XXX 15 bits hole, try to pack */
> >         /* Bitfield combined with next fields */
> >
> >         __u64                      netns_dev;            /*    86     8 */
> 
> I guess that should be "__aligned_u64 netns_dev;", to not rely on
> implicit alignment.

This is exactly the fix we suggested a year ago in
https://lore.kernel.org/lkml/20180527112842.GA18204@asgard.redhat.com/T/#u
when the issue arose for the first time, but, unfortunately,
bpf maintainers took a more error-prone approach.

I suppose our initial fix is still applicable.

> > And this is for the strace struct:
> >
> > struct bpf_prog_info_struct {
> >         ...
> >         uint32_t                   ifindex;              /*    80     4 */
> >         uint32_t                   gpl_compatible:1;     /*    84: 0  4 */
> >
> >         /* XXX 31 bits hole, try to pack */
> 
> How come the uint64_t below is 8-byte aligned, not 2-byte aligned?
> Does strace use a special definition of uint64_t?
> 
> >
> >         uint64_t                   netns_dev;            /*    88     8 */
> >
> > How should this be fixed?
> 
> IMHO all "__u64" in structs tagged "__attribute__((aligned(8)))" should
> be replaced by "__aligned_u64", which is what the (whitespace-damaged)
> diff below does.

This is the approach taken in strace, see e.g.
https://gitlab.com/strace/strace/blob/master/bpf_attr.h#L13

When <linux/bpf.h> in the kernel fails to set proper offsets,
a static assertion in strace is triggered.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20190503/d595c0df/attachment.bin>