[PATCH bpf 3/4] bpf: Ensure unit_size is matched with slab cache object size

[Alexei Starovoitov]

On Fri, Sep 29, 2023 at 1:24 PM Lad, Prabhakar
<prabhakar.csengg at gmail.com> wrote:
>
> On Fri, Sep 29, 2023 at 7:52 PM Emil Renner Berthing
> <emil.renner.berthing at canonical.com> wrote:
> >
> > Guenter Roeck wrote:
> > > Hi,
> > >
> > > On Fri, Sep 08, 2023 at 09:39:22PM +0800, Hou Tao wrote:
> > > > From: Hou Tao <houtao1 at huawei.com>
> > > >
> > > > Add extra check in bpf_mem_alloc_init() to ensure the unit_size of
> > > > bpf_mem_cache is matched with the object_size of underlying slab cache.
> > > > If these two sizes are unmatched, print a warning once and return
> > > > -EINVAL in bpf_mem_alloc_init(), so the mismatch can be found early and
> > > > the potential issue can be prevented.
> > > >
> > > > Suggested-by: Alexei Starovoitov <ast at kernel.org>
> > > > Signed-off-by: Hou Tao <houtao1 at huawei.com>
> > >
> > > With this patch in place, I see the following backtrace on riscv systems.
> > >
> > > [    2.953088] bpf_mem_cache[0]: unexpected object size 128, expect 96
> > > [    2.953481] WARNING: CPU: 0 PID: 1 at kernel/bpf/memalloc.c:507 bpf_mem_alloc_init+0x326/0x32e
> > > [    2.953645] Modules linked in:
> > > [    2.953736] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.0-rc2-00244-g27bbf45eae9c #1
> > > [    2.953790] Hardware name: riscv-virtio,qemu (DT)
> > > [    2.953855] epc : bpf_mem_alloc_init+0x326/0x32e
> > > [    2.953891]  ra : bpf_mem_alloc_init+0x326/0x32e
> > > [    2.953909] epc : ffffffff8016cbd2 ra : ffffffff8016cbd2 sp : ff2000000000bd20
> > > [    2.953920]  gp : ffffffff81c39298 tp : ff60000002e80040 t0 : 0000000000000000
> > > [    2.953930]  t1 : ffffffffbbbabbc3 t2 : 635f6d656d5f6670 s0 : ff2000000000bdc0
> > > [    2.953940]  s1 : ffffffff8121c7da a0 : 0000000000000037 a1 : ffffffff81a93048
> > > [    2.953949]  a2 : 0000000000000010 a3 : 0000000000000001 a4 : 0000000000000000
> > > [    2.953959]  a5 : 0000000000000000 a6 : ffffffff81c4fe08 a7 : 0000000000000000
> > > [    2.953968]  s2 : 000000000000000b s3 : 0000000000000000 s4 : 0000000000000000
> > > [    2.953977]  s5 : 0000000000000000 s6 : 0000000000000100 s7 : ff5ffffffffd3128
> > > [    2.953986]  s8 : ffffffff81c3d1f8 s9 : 0000000000000060 s10: 0000000000000000
> > > [    2.953996]  s11: 0000000000000060 t3 : 0000000065a61b33 t4 : 0000000000000009
> > > [    2.954005]  t5 : ffffffffde180000 t6 : ff2000000000bb08
> > > [    2.954014] status: 0000000200000120 badaddr: 0000000000000000 cause: 0000000000000003
> > > [    2.954047] [<ffffffff8016cbd2>] bpf_mem_alloc_init+0x326/0x32e
> > > [    2.954087] [<ffffffff80e11426>] bpf_global_ma_init+0x1c/0x30
> > > [    2.954097] [<ffffffff8000285e>] do_one_initcall+0x5c/0x238
> > > [    2.954105] [<ffffffff80e011ae>] kernel_init_freeable+0x29a/0x30e
> > > [    2.954115] [<ffffffff80c0312c>] kernel_init+0x1e/0x112
> > > [    2.954124] [<ffffffff80003d82>] ret_from_fork+0xa/0x1c
> > >
> > > Copying riscv maintainers and mailing list for feedback / comments.
> >
> > If it makes a difference I also see this with 6.6-rc3 on my Nezha board
> > (Allwinner D1), but not on my VisionFive 2 (JH7110) running the same kernel.
> >
>
> Adding one more RISC-V board (Renesas RZ/Five) to list where I see this issue:

Could you please help test the proposed fix:
https://patchwork.kernel.org/project/netdevbpf/patch/20230928101558.2594068-1-houtao@huaweicloud.com/