[PATCH bpf 3/4] bpf: Ensure unit_size is matched with slab cache object size
Emil Renner Berthing
emil.renner.berthing at canonical.com
Fri Sep 29 11:51:13 PDT 2023
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.
/Emil
More information about the linux-riscv
mailing list