On Wed, Apr 3, 2024 at 6:14 AM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote:
>
> On 4/3/24 2:33 PM, Anton Protopopov wrote:
> > The struct bpf_fib_lookup is supposed to be of size 64. A recent commit
> > 59b418c7063d ("bpf: Add a check for struct bpf_fib_lookup size") added
> > a static assertion to check this property so that future changes to the
> > structure will not accidentally break this assumption.
> >
> > As it immediately turned out, on some 32-bit arm systems, when AEABI=n,
> > the total size of the structure was equal to 68, see [1]. This happened
> > because the bpf_fib_lookup structure contains a union of two 16-bit
> > fields:
> >
> > union {
> > __u16 tot_len;
> > __u16 mtu_result;
> > };
> >
> > which was supposed to compile to a 16-bit-aligned 16-bit field. On the
> > aforementioned setups it was instead both aligned and padded to 32-bits.
> >
> > Declare this inner union as __attribute__((packed, aligned(2))) such
> > that it always is of size 2 and is aligned to 16 bits.
> >
> > [1] https://lore.kernel.org/all/CA+G9fYtsoP51f-oP_Sp5MOq-Ffv8La2RztNpwvE6+R1VtFiLrw@xxxxxxxxxxxxxx/#t
> >
> > Signed-off-by: Anton Protopopov <aspsk@xxxxxxxxxxxxx>
>
> Reported-by: Naresh Kamboju <naresh.kamboju@xxxxxxxxxx>
> Acked-by: Daniel Borkmann <daniel@xxxxxxxxxxxxx>
Let's continue the tag fest :) Also fixes tag:
Fixes: e1850ea9bd9e ("bpf: bpf_fib_lookup return MTU value as output
when looked up")
Should this also go through the bpf tree instead of bpf-next?
