* Re: next/master bisection: baseline.login on qemu_arm64-virt-gicv3-uefi [not found] <65e9e748.a70a0220.606f7.53c0@mx.google.com> @ 2024-03-07 16:36 ` Mark Brown 2024-03-07 18:16 ` Song Liu 0 siblings, 1 reply; 6+ messages in thread From: Mark Brown @ 2024-03-07 16:36 UTC (permalink / raw) To: Puranjay Mohan, Song Liu, Catalin Marinas, Alexei Starovoitov, Will Deacon Cc: kernelci-results, bot, linux-arm-kernel, linux-mm, bpf, linux-next [-- Attachment #1: Type: text/plain, Size: 17605 bytes --] On Thu, Mar 07, 2024 at 08:12:00AM -0800, KernelCI bot wrote: The KernelCI bisection bot found a boot regression n today's -next on qemu arm64 UEFI platforms with 64K pages which was bisected to commit 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management"). We OOM quite early in boot: <6>[ 0.174998] DMI: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 <4>[ 0.189015] swapper/0 invoked oom-killer: gfp_mask=0x2cc2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_NOWARN), order=0, oom_score_adj=0 <4>[ 0.189835] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc7-next-20240307 #1 <4>[ 0.190093] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 ... <4>[ 0.192209] vmalloc+0x84/0x94 <4>[ 0.192301] bpf_jit_alloc_exec+0x10/0x1c <4>[ 0.192402] bpf_prog_pack_alloc+0x120/0x26c <4>[ 0.192505] bpf_jit_binary_pack_alloc+0x6c/0x128 <4>[ 0.192611] bpf_int_jit_compile+0x5f4/0x69c <4>[ 0.192718] bpf_prog_select_runtime+0x11c/0x194 <4>[ 0.192832] bpf_migrate_filter+0x120/0x164 <4>[ 0.192940] bpf_prog_create+0x124/0x154 <4>[ 0.193045] ptp_classifier_init+0x40/0x70 <4>[ 0.193152] sock_init+0xa4/0xbc It just seems to be these platforms that are affected, the same platforms without UEFI are fine and no other platforms seem to be showing similar behaviour. A full log from one of the failed boots can be seen here: https://storage.kernelci.org/next/master/next-20240307/arm64/defconfig+CONFIG_ARM64_64K_PAGES=y/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv2-uefi.txt I've left the full report from the bot below, including links to other boot logs and further information as well as a Reported-by for the bot. > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * This automated bisection report was sent to you on the basis * > * that you may be involved with the breaking commit it has * > * found. No manual investigation has been done to verify it, * > * and the root cause of the problem may be somewhere else. * > * * > * If you do send a fix, please include this trailer: * > * Reported-by: "kernelci.org bot" <bot@kernelci.org> * > * * > * Hope this helps! * > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > next/master bisection: baseline.login on qemu_arm64-virt-gicv3-uefi > > Summary: > Start: 1843e16d2df9 Add linux-next specific files for 20240307 > Plain log: https://storage.kernelci.org/next/master/next-20240307/arm64/defconfig+CONFIG_ARM64_64K_PAGES=y/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv3-uefi.txt > HTML log: https://storage.kernelci.org/next/master/next-20240307/arm64/defconfig+CONFIG_ARM64_64K_PAGES=y/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv3-uefi.html > Result: 1dad391daef1 bpf, arm64: use bpf_prog_pack for memory management > > Checks: > revert: PASS > verify: PASS > > Parameters: > Tree: next > URL: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > Branch: master > Target: qemu_arm64-virt-gicv3-uefi > CPU arch: arm64 > Lab: lab-collabora > Compiler: gcc-10 > Config: defconfig+CONFIG_ARM64_64K_PAGES=y > Test case: baseline.login > > Breaking commit found: > > ------------------------------------------------------------------------------- > commit 1dad391daef129e01e28206b8d586608ff026548 > Author: Puranjay Mohan <puranjay12@gmail.com> > Date: Wed Feb 28 14:18:24 2024 +0000 > > bpf, arm64: use bpf_prog_pack for memory management > > Use bpf_jit_binary_pack_alloc for memory management of JIT binaries in > ARM64 BPF JIT. The bpf_jit_binary_pack_alloc creates a pair of RW and RX > buffers. The JIT writes the program into the RW buffer. When the JIT is > done, the program is copied to the final RX buffer > with bpf_jit_binary_pack_finalize. > > Implement bpf_arch_text_copy() and bpf_arch_text_invalidate() for ARM64 > JIT as these functions are required by bpf_jit_binary_pack allocator. > > Signed-off-by: Puranjay Mohan <puranjay12@gmail.com> > Acked-by: Song Liu <song@kernel.org> > Acked-by: Catalin Marinas <catalin.marinas@arm.com> > Link: https://lore.kernel.org/r/20240228141824.119877-3-puranjay12@gmail.com > Signed-off-by: Alexei Starovoitov <ast@kernel.org> > > diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c > index 20720ec346b8..5afc7a525eca 100644 > --- a/arch/arm64/net/bpf_jit_comp.c > +++ b/arch/arm64/net/bpf_jit_comp.c > @@ -76,6 +76,7 @@ struct jit_ctx { > int *offset; > int exentry_idx; > __le32 *image; > + __le32 *ro_image; > u32 stack_size; > int fpb_offset; > }; > @@ -205,6 +206,14 @@ static void jit_fill_hole(void *area, unsigned int size) > *ptr++ = cpu_to_le32(AARCH64_BREAK_FAULT); > } > > +int bpf_arch_text_invalidate(void *dst, size_t len) > +{ > + if (!aarch64_insn_set(dst, AARCH64_BREAK_FAULT, len)) > + return -EINVAL; > + > + return 0; > +} > + > static inline int epilogue_offset(const struct jit_ctx *ctx) > { > int to = ctx->epilogue_offset; > @@ -746,7 +755,8 @@ static int add_exception_handler(const struct bpf_insn *insn, > struct jit_ctx *ctx, > int dst_reg) > { > - off_t offset; > + off_t ins_offset; > + off_t fixup_offset; > unsigned long pc; > struct exception_table_entry *ex; > > @@ -763,12 +773,17 @@ static int add_exception_handler(const struct bpf_insn *insn, > return -EINVAL; > > ex = &ctx->prog->aux->extable[ctx->exentry_idx]; > - pc = (unsigned long)&ctx->image[ctx->idx - 1]; > + pc = (unsigned long)&ctx->ro_image[ctx->idx - 1]; > > - offset = pc - (long)&ex->insn; > - if (WARN_ON_ONCE(offset >= 0 || offset < INT_MIN)) > + /* > + * This is the relative offset of the instruction that may fault from > + * the exception table itself. This will be written to the exception > + * table and if this instruction faults, the destination register will > + * be set to '0' and the execution will jump to the next instruction. > + */ > + ins_offset = pc - (long)&ex->insn; > + if (WARN_ON_ONCE(ins_offset >= 0 || ins_offset < INT_MIN)) > return -ERANGE; > - ex->insn = offset; > > /* > * Since the extable follows the program, the fixup offset is always > @@ -777,12 +792,25 @@ static int add_exception_handler(const struct bpf_insn *insn, > * bits. We don't need to worry about buildtime or runtime sort > * modifying the upper bits because the table is already sorted, and > * isn't part of the main exception table. > + * > + * The fixup_offset is set to the next instruction from the instruction > + * that may fault. The execution will jump to this after handling the > + * fault. > */ > - offset = (long)&ex->fixup - (pc + AARCH64_INSN_SIZE); > - if (!FIELD_FIT(BPF_FIXUP_OFFSET_MASK, offset)) > + fixup_offset = (long)&ex->fixup - (pc + AARCH64_INSN_SIZE); > + if (!FIELD_FIT(BPF_FIXUP_OFFSET_MASK, fixup_offset)) > return -ERANGE; > > - ex->fixup = FIELD_PREP(BPF_FIXUP_OFFSET_MASK, offset) | > + /* > + * The offsets above have been calculated using the RO buffer but we > + * need to use the R/W buffer for writes. > + * switch ex to rw buffer for writing. > + */ > + ex = (void *)ctx->image + ((void *)ex - (void *)ctx->ro_image); > + > + ex->insn = ins_offset; > + > + ex->fixup = FIELD_PREP(BPF_FIXUP_OFFSET_MASK, fixup_offset) | > FIELD_PREP(BPF_FIXUP_REG_MASK, dst_reg); > > ex->type = EX_TYPE_BPF; > @@ -1550,7 +1578,8 @@ static inline void bpf_flush_icache(void *start, void *end) > > struct arm64_jit_data { > struct bpf_binary_header *header; > - u8 *image; > + u8 *ro_image; > + struct bpf_binary_header *ro_header; > struct jit_ctx ctx; > }; > > @@ -1559,12 +1588,14 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) > int image_size, prog_size, extable_size, extable_align, extable_offset; > struct bpf_prog *tmp, *orig_prog = prog; > struct bpf_binary_header *header; > + struct bpf_binary_header *ro_header; > struct arm64_jit_data *jit_data; > bool was_classic = bpf_prog_was_classic(prog); > bool tmp_blinded = false; > bool extra_pass = false; > struct jit_ctx ctx; > u8 *image_ptr; > + u8 *ro_image_ptr; > > if (!prog->jit_requested) > return orig_prog; > @@ -1591,8 +1622,11 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) > } > if (jit_data->ctx.offset) { > ctx = jit_data->ctx; > - image_ptr = jit_data->image; > + ro_image_ptr = jit_data->ro_image; > + ro_header = jit_data->ro_header; > header = jit_data->header; > + image_ptr = (void *)header + ((void *)ro_image_ptr > + - (void *)ro_header); > extra_pass = true; > prog_size = sizeof(u32) * ctx.idx; > goto skip_init_ctx; > @@ -1637,18 +1671,27 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) > /* also allocate space for plt target */ > extable_offset = round_up(prog_size + PLT_TARGET_SIZE, extable_align); > image_size = extable_offset + extable_size; > - header = bpf_jit_binary_alloc(image_size, &image_ptr, > - sizeof(u32), jit_fill_hole); > - if (header == NULL) { > + ro_header = bpf_jit_binary_pack_alloc(image_size, &ro_image_ptr, > + sizeof(u32), &header, &image_ptr, > + jit_fill_hole); > + if (!ro_header) { > prog = orig_prog; > goto out_off; > } > > /* 2. Now, the actual pass. */ > > + /* > + * Use the image(RW) for writing the JITed instructions. But also save > + * the ro_image(RX) for calculating the offsets in the image. The RW > + * image will be later copied to the RX image from where the program > + * will run. The bpf_jit_binary_pack_finalize() will do this copy in the > + * final step. > + */ > ctx.image = (__le32 *)image_ptr; > + ctx.ro_image = (__le32 *)ro_image_ptr; > if (extable_size) > - prog->aux->extable = (void *)image_ptr + extable_offset; > + prog->aux->extable = (void *)ro_image_ptr + extable_offset; > skip_init_ctx: > ctx.idx = 0; > ctx.exentry_idx = 0; > @@ -1656,9 +1699,8 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) > build_prologue(&ctx, was_classic, prog->aux->exception_cb); > > if (build_body(&ctx, extra_pass)) { > - bpf_jit_binary_free(header); > prog = orig_prog; > - goto out_off; > + goto out_free_hdr; > } > > build_epilogue(&ctx, prog->aux->exception_cb); > @@ -1666,34 +1708,44 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) > > /* 3. Extra pass to validate JITed code. */ > if (validate_ctx(&ctx)) { > - bpf_jit_binary_free(header); > prog = orig_prog; > - goto out_off; > + goto out_free_hdr; > } > > /* And we're done. */ > if (bpf_jit_enable > 1) > bpf_jit_dump(prog->len, prog_size, 2, ctx.image); > > - bpf_flush_icache(header, ctx.image + ctx.idx); > - > if (!prog->is_func || extra_pass) { > if (extra_pass && ctx.idx != jit_data->ctx.idx) { > pr_err_once("multi-func JIT bug %d != %d\n", > ctx.idx, jit_data->ctx.idx); > - bpf_jit_binary_free(header); > prog->bpf_func = NULL; > prog->jited = 0; > prog->jited_len = 0; > + goto out_free_hdr; > + } > + if (WARN_ON(bpf_jit_binary_pack_finalize(prog, ro_header, > + header))) { > + /* ro_header has been freed */ > + ro_header = NULL; > + prog = orig_prog; > goto out_off; > } > - bpf_jit_binary_lock_ro(header); > + /* > + * The instructions have now been copied to the ROX region from > + * where they will execute. Now the data cache has to be cleaned to > + * the PoU and the I-cache has to be invalidated for the VAs. > + */ > + bpf_flush_icache(ro_header, ctx.ro_image + ctx.idx); > } else { > jit_data->ctx = ctx; > - jit_data->image = image_ptr; > + jit_data->ro_image = ro_image_ptr; > jit_data->header = header; > + jit_data->ro_header = ro_header; > } > - prog->bpf_func = (void *)ctx.image; > + > + prog->bpf_func = (void *)ctx.ro_image; > prog->jited = 1; > prog->jited_len = prog_size; > > @@ -1714,6 +1766,14 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) > bpf_jit_prog_release_other(prog, prog == orig_prog ? > tmp : orig_prog); > return prog; > + > +out_free_hdr: > + if (header) { > + bpf_arch_text_copy(&ro_header->size, &header->size, > + sizeof(header->size)); > + bpf_jit_binary_pack_free(ro_header, header); > + } > + goto out_off; > } > > bool bpf_jit_supports_kfunc_call(void) > @@ -1721,6 +1781,13 @@ bool bpf_jit_supports_kfunc_call(void) > return true; > } > > +void *bpf_arch_text_copy(void *dst, void *src, size_t len) > +{ > + if (!aarch64_insn_copy(dst, src, len)) > + return ERR_PTR(-EINVAL); > + return dst; > +} > + > u64 bpf_jit_alloc_exec_limit(void) > { > return VMALLOC_END - VMALLOC_START; > @@ -2359,3 +2426,27 @@ bool bpf_jit_supports_exceptions(void) > */ > return true; > } > + > +void bpf_jit_free(struct bpf_prog *prog) > +{ > + if (prog->jited) { > + struct arm64_jit_data *jit_data = prog->aux->jit_data; > + struct bpf_binary_header *hdr; > + > + /* > + * If we fail the final pass of JIT (from jit_subprogs), > + * the program may not be finalized yet. Call finalize here > + * before freeing it. > + */ > + if (jit_data) { > + bpf_arch_text_copy(&jit_data->ro_header->size, &jit_data->header->size, > + sizeof(jit_data->header->size)); > + kfree(jit_data); > + } > + hdr = bpf_jit_binary_pack_hdr(prog); > + bpf_jit_binary_pack_free(hdr, NULL); > + WARN_ON_ONCE(!bpf_prog_kallsyms_verify_off(prog)); > + } > + > + bpf_prog_unlock_free(prog); > +} > ------------------------------------------------------------------------------- > > > Git bisection log: > > ------------------------------------------------------------------------------- > git bisect start > # good: [67be068d31d423b857ffd8c34dbcc093f8dfff76] Merge tag 'vfs-6.8-release.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs > git bisect good 67be068d31d423b857ffd8c34dbcc093f8dfff76 > # bad: [1843e16d2df9d98427ef8045589571749d627cf7] Add linux-next specific files for 20240307 > git bisect bad 1843e16d2df9d98427ef8045589571749d627cf7 > # bad: [1a0a33e22e715a4cc7bb2709cfda8e83b8c756b2] Merge branch 'main' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git > git bisect bad 1a0a33e22e715a4cc7bb2709cfda8e83b8c756b2 > # good: [5a0d6b0465ab18fefa8abc9afbabce19e7de2fe5] Merge branch 'nfsd-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux > git bisect good 5a0d6b0465ab18fefa8abc9afbabce19e7de2fe5 > # good: [a5fcf74d80bec9948701ff0f7529ae96a0c4a41c] inet: annotate data-races around ifa->ifa_valid_lft > git bisect good a5fcf74d80bec9948701ff0f7529ae96a0c4a41c > # good: [7aaab3e1fcee995b70d344687fa0f33b0b9d33f7] Merge branch 'hwmon-next' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git > git bisect good 7aaab3e1fcee995b70d344687fa0f33b0b9d33f7 > # good: [dfa2c103738019033bad44d8be7919ad8bc19dd6] Merge branch 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git > git bisect good dfa2c103738019033bad44d8be7919ad8bc19dd6 > # bad: [564ae6794ec5f050bb6df4446820777e7253f960] mptcp: get addr in userspace pm list > git bisect bad 564ae6794ec5f050bb6df4446820777e7253f960 > # good: [2c21a0f67c8ce334b8a58332e8c2d71694bef0ab] Merge branch 'Support PTR_MAYBE_NULL for struct_ops arguments.' > git bisect good 2c21a0f67c8ce334b8a58332e8c2d71694bef0ab > # bad: [4ab597d2962195ca4f01a429f9b2ea87ee684be3] net: bareudp: Remove generic .ndo_get_stats64 > git bisect bad 4ab597d2962195ca4f01a429f9b2ea87ee684be3 > # good: [dfe6625df48ec54c6dc9b86d361f26962d09de88] bpf: introduce in_sleepable() helper > git bisect good dfe6625df48ec54c6dc9b86d361f26962d09de88 > # bad: [f2e81192e07e87897ff1296c96775eceea8f582a] bpftool: Add an example for struct_ops map and shadow type. > git bisect bad f2e81192e07e87897ff1296c96775eceea8f582a > # bad: [1dad391daef129e01e28206b8d586608ff026548] bpf, arm64: use bpf_prog_pack for memory management > git bisect bad 1dad391daef129e01e28206b8d586608ff026548 > # good: [22fc0e80aeb5c0c1377e6c02d7248f8fbf5df7fc] bpf, arm64: support exceptions > git bisect good 22fc0e80aeb5c0c1377e6c02d7248f8fbf5df7fc > # good: [451c3cab9a65e656c3b3d106831fc02d56b8c34a] arm64: patching: implement text_poke API > git bisect good 451c3cab9a65e656c3b3d106831fc02d56b8c34a > # first bad commit: [1dad391daef129e01e28206b8d586608ff026548] bpf, arm64: use bpf_prog_pack for memory management > ------------------------------------------------------------------------------- > > > -=-=-=-=-=-=-=-=-=-=-=- > Groups.io Links: You receive all messages sent to this group. > View/Reply Online (#52295): https://groups.io/g/kernelci-results/message/52295 > Mute This Topic: https://groups.io/mt/104790392/1131744 > Group Owner: kernelci-results+owner@groups.io > Unsubscribe: https://groups.io/g/kernelci-results/unsub [broonie@kernel.org] > -=-=-=-=-=-=-=-=-=-=-=- > > [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: next/master bisection: baseline.login on qemu_arm64-virt-gicv3-uefi 2024-03-07 16:36 ` next/master bisection: baseline.login on qemu_arm64-virt-gicv3-uefi Mark Brown @ 2024-03-07 18:16 ` Song Liu 2024-03-07 18:34 ` Mark Brown 0 siblings, 1 reply; 6+ messages in thread From: Song Liu @ 2024-03-07 18:16 UTC (permalink / raw) To: Mark Brown Cc: Puranjay Mohan, Catalin Marinas, Alexei Starovoitov, Will Deacon, kernelci-results, bot, linux-arm-kernel, linux-mm, bpf, linux-next On Thu, Mar 7, 2024 at 8:36 AM Mark Brown <broonie@kernel.org> wrote: > > On Thu, Mar 07, 2024 at 08:12:00AM -0800, KernelCI bot wrote: > > The KernelCI bisection bot found a boot regression n today's -next on > qemu arm64 UEFI platforms with 64K pages which was bisected to commit > 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management"). > We OOM quite early in boot: IIUC, 64kB pages means 512MB PMD. I think that's indeed too big. We will need some logic to limit such cases. Song > > <6>[ 0.174998] DMI: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 > <4>[ 0.189015] swapper/0 invoked oom-killer: gfp_mask=0x2cc2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_NOWARN), order=0, oom_score_adj=0 > <4>[ 0.189835] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc7-next-20240307 #1 > <4>[ 0.190093] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 > > ... > > > <4>[ 0.192209] vmalloc+0x84/0x94 > <4>[ 0.192301] bpf_jit_alloc_exec+0x10/0x1c > <4>[ 0.192402] bpf_prog_pack_alloc+0x120/0x26c > <4>[ 0.192505] bpf_jit_binary_pack_alloc+0x6c/0x128 > <4>[ 0.192611] bpf_int_jit_compile+0x5f4/0x69c > <4>[ 0.192718] bpf_prog_select_runtime+0x11c/0x194 > <4>[ 0.192832] bpf_migrate_filter+0x120/0x164 > <4>[ 0.192940] bpf_prog_create+0x124/0x154 > <4>[ 0.193045] ptp_classifier_init+0x40/0x70 > <4>[ 0.193152] sock_init+0xa4/0xbc > > It just seems to be these platforms that are affected, the same > platforms without UEFI are fine and no other platforms seem to be > showing similar behaviour. A full log from one of the failed boots can > be seen here: > > https://storage.kernelci.org/next/master/next-20240307/arm64/defconfig+CONFIG_ARM64_64K_PAGES=y/gcc-10/lab-broonie/baseline-qemu_arm64-virt-gicv2-uefi.txt > > I've left the full report from the bot below, including links to other > boot logs and further information as well as a Reported-by for the bot. > > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > * This automated bisection report was sent to you on the basis * > > * that you may be involved with the breaking commit it has * > > * found. No manual investigation has been done to verify it, * > > * and the root cause of the problem may be somewhere else. * > > * * > > * If you do send a fix, please include this trailer: * > > * Reported-by: "kernelci.org bot" <bot@kernelci.org> * > > * * > > * Hope this helps! * > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > > > next/master bisection: baseline.login on qemu_arm64-virt-gicv3-uefi > > > > Summary: > > Start: 1843e16d2df9 Add linux-next specific files for 20240307 > > Plain log: https://storage.kernelci.org/next/master/next-20240307/arm64/defconfig+CONFIG_ARM64_64K_PAGES=y/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv3-uefi.txt > > HTML log: https://storage.kernelci.org/next/master/next-20240307/arm64/defconfig+CONFIG_ARM64_64K_PAGES=y/gcc-10/lab-collabora/baseline-qemu_arm64-virt-gicv3-uefi.html > > Result: 1dad391daef1 bpf, arm64: use bpf_prog_pack for memory management > > > > Checks: > > revert: PASS > > verify: PASS > > > > Parameters: > > Tree: next > > URL: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > > Branch: master > > Target: qemu_arm64-virt-gicv3-uefi > > CPU arch: arm64 > > Lab: lab-collabora > > Compiler: gcc-10 > > Config: defconfig+CONFIG_ARM64_64K_PAGES=y > > Test case: baseline.login > > > > Breaking commit found: > > > > ------------------------------------------------------------------------------- > > commit 1dad391daef129e01e28206b8d586608ff026548 > > Author: Puranjay Mohan <puranjay12@gmail.com> > > Date: Wed Feb 28 14:18:24 2024 +0000 > > > > bpf, arm64: use bpf_prog_pack for memory management > > > > Use bpf_jit_binary_pack_alloc for memory management of JIT binaries in > > ARM64 BPF JIT. The bpf_jit_binary_pack_alloc creates a pair of RW and RX > > buffers. The JIT writes the program into the RW buffer. When the JIT is > > done, the program is copied to the final RX buffer > > with bpf_jit_binary_pack_finalize. > > > > Implement bpf_arch_text_copy() and bpf_arch_text_invalidate() for ARM64 > > JIT as these functions are required by bpf_jit_binary_pack allocator. > > > > Signed-off-by: Puranjay Mohan <puranjay12@gmail.com> > > Acked-by: Song Liu <song@kernel.org> > > Acked-by: Catalin Marinas <catalin.marinas@arm.com> > > Link: https://lore.kernel.org/r/20240228141824.119877-3-puranjay12@gmail.com > > Signed-off-by: Alexei Starovoitov <ast@kernel.org> > > > > diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c > > index 20720ec346b8..5afc7a525eca 100644 > > --- a/arch/arm64/net/bpf_jit_comp.c > > +++ b/arch/arm64/net/bpf_jit_comp.c > > @@ -76,6 +76,7 @@ struct jit_ctx { > > int *offset; > > int exentry_idx; > > __le32 *image; > > + __le32 *ro_image; > > u32 stack_size; > > int fpb_offset; > > }; > > @@ -205,6 +206,14 @@ static void jit_fill_hole(void *area, unsigned int size) > > *ptr++ = cpu_to_le32(AARCH64_BREAK_FAULT); > > } > > > > +int bpf_arch_text_invalidate(void *dst, size_t len) > > +{ > > + if (!aarch64_insn_set(dst, AARCH64_BREAK_FAULT, len)) > > + return -EINVAL; > > + > > + return 0; > > +} > > + > > static inline int epilogue_offset(const struct jit_ctx *ctx) > > { > > int to = ctx->epilogue_offset; > > @@ -746,7 +755,8 @@ static int add_exception_handler(const struct bpf_insn *insn, > > struct jit_ctx *ctx, > > int dst_reg) > > { > > - off_t offset; > > + off_t ins_offset; > > + off_t fixup_offset; > > unsigned long pc; > > struct exception_table_entry *ex; > > > > @@ -763,12 +773,17 @@ static int add_exception_handler(const struct bpf_insn *insn, > > return -EINVAL; > > > > ex = &ctx->prog->aux->extable[ctx->exentry_idx]; > > - pc = (unsigned long)&ctx->image[ctx->idx - 1]; > > + pc = (unsigned long)&ctx->ro_image[ctx->idx - 1]; > > > > - offset = pc - (long)&ex->insn; > > - if (WARN_ON_ONCE(offset >= 0 || offset < INT_MIN)) > > + /* > > + * This is the relative offset of the instruction that may fault from > > + * the exception table itself. This will be written to the exception > > + * table and if this instruction faults, the destination register will > > + * be set to '0' and the execution will jump to the next instruction. > > + */ > > + ins_offset = pc - (long)&ex->insn; > > + if (WARN_ON_ONCE(ins_offset >= 0 || ins_offset < INT_MIN)) > > return -ERANGE; > > - ex->insn = offset; > > > > /* > > * Since the extable follows the program, the fixup offset is always > > @@ -777,12 +792,25 @@ static int add_exception_handler(const struct bpf_insn *insn, > > * bits. We don't need to worry about buildtime or runtime sort > > * modifying the upper bits because the table is already sorted, and > > * isn't part of the main exception table. > > + * > > + * The fixup_offset is set to the next instruction from the instruction > > + * that may fault. The execution will jump to this after handling the > > + * fault. > > */ > > - offset = (long)&ex->fixup - (pc + AARCH64_INSN_SIZE); > > - if (!FIELD_FIT(BPF_FIXUP_OFFSET_MASK, offset)) > > + fixup_offset = (long)&ex->fixup - (pc + AARCH64_INSN_SIZE); > > + if (!FIELD_FIT(BPF_FIXUP_OFFSET_MASK, fixup_offset)) > > return -ERANGE; > > > > - ex->fixup = FIELD_PREP(BPF_FIXUP_OFFSET_MASK, offset) | > > + /* > > + * The offsets above have been calculated using the RO buffer but we > > + * need to use the R/W buffer for writes. > > + * switch ex to rw buffer for writing. > > + */ > > + ex = (void *)ctx->image + ((void *)ex - (void *)ctx->ro_image); > > + > > + ex->insn = ins_offset; > > + > > + ex->fixup = FIELD_PREP(BPF_FIXUP_OFFSET_MASK, fixup_offset) | > > FIELD_PREP(BPF_FIXUP_REG_MASK, dst_reg); > > > > ex->type = EX_TYPE_BPF; > > @@ -1550,7 +1578,8 @@ static inline void bpf_flush_icache(void *start, void *end) > > > > struct arm64_jit_data { > > struct bpf_binary_header *header; > > - u8 *image; > > + u8 *ro_image; > > + struct bpf_binary_header *ro_header; > > struct jit_ctx ctx; > > }; > > > > @@ -1559,12 +1588,14 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) > > int image_size, prog_size, extable_size, extable_align, extable_offset; > > struct bpf_prog *tmp, *orig_prog = prog; > > struct bpf_binary_header *header; > > + struct bpf_binary_header *ro_header; > > struct arm64_jit_data *jit_data; > > bool was_classic = bpf_prog_was_classic(prog); > > bool tmp_blinded = false; > > bool extra_pass = false; > > struct jit_ctx ctx; > > u8 *image_ptr; > > + u8 *ro_image_ptr; > > > > if (!prog->jit_requested) > > return orig_prog; > > @@ -1591,8 +1622,11 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) > > } > > if (jit_data->ctx.offset) { > > ctx = jit_data->ctx; > > - image_ptr = jit_data->image; > > + ro_image_ptr = jit_data->ro_image; > > + ro_header = jit_data->ro_header; > > header = jit_data->header; > > + image_ptr = (void *)header + ((void *)ro_image_ptr > > + - (void *)ro_header); > > extra_pass = true; > > prog_size = sizeof(u32) * ctx.idx; > > goto skip_init_ctx; > > @@ -1637,18 +1671,27 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) > > /* also allocate space for plt target */ > > extable_offset = round_up(prog_size + PLT_TARGET_SIZE, extable_align); > > image_size = extable_offset + extable_size; > > - header = bpf_jit_binary_alloc(image_size, &image_ptr, > > - sizeof(u32), jit_fill_hole); > > - if (header == NULL) { > > + ro_header = bpf_jit_binary_pack_alloc(image_size, &ro_image_ptr, > > + sizeof(u32), &header, &image_ptr, > > + jit_fill_hole); > > + if (!ro_header) { > > prog = orig_prog; > > goto out_off; > > } > > > > /* 2. Now, the actual pass. */ > > > > + /* > > + * Use the image(RW) for writing the JITed instructions. But also save > > + * the ro_image(RX) for calculating the offsets in the image. The RW > > + * image will be later copied to the RX image from where the program > > + * will run. The bpf_jit_binary_pack_finalize() will do this copy in the > > + * final step. > > + */ > > ctx.image = (__le32 *)image_ptr; > > + ctx.ro_image = (__le32 *)ro_image_ptr; > > if (extable_size) > > - prog->aux->extable = (void *)image_ptr + extable_offset; > > + prog->aux->extable = (void *)ro_image_ptr + extable_offset; > > skip_init_ctx: > > ctx.idx = 0; > > ctx.exentry_idx = 0; > > @@ -1656,9 +1699,8 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) > > build_prologue(&ctx, was_classic, prog->aux->exception_cb); > > > > if (build_body(&ctx, extra_pass)) { > > - bpf_jit_binary_free(header); > > prog = orig_prog; > > - goto out_off; > > + goto out_free_hdr; > > } > > > > build_epilogue(&ctx, prog->aux->exception_cb); > > @@ -1666,34 +1708,44 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) > > > > /* 3. Extra pass to validate JITed code. */ > > if (validate_ctx(&ctx)) { > > - bpf_jit_binary_free(header); > > prog = orig_prog; > > - goto out_off; > > + goto out_free_hdr; > > } > > > > /* And we're done. */ > > if (bpf_jit_enable > 1) > > bpf_jit_dump(prog->len, prog_size, 2, ctx.image); > > > > - bpf_flush_icache(header, ctx.image + ctx.idx); > > - > > if (!prog->is_func || extra_pass) { > > if (extra_pass && ctx.idx != jit_data->ctx.idx) { > > pr_err_once("multi-func JIT bug %d != %d\n", > > ctx.idx, jit_data->ctx.idx); > > - bpf_jit_binary_free(header); > > prog->bpf_func = NULL; > > prog->jited = 0; > > prog->jited_len = 0; > > + goto out_free_hdr; > > + } > > + if (WARN_ON(bpf_jit_binary_pack_finalize(prog, ro_header, > > + header))) { > > + /* ro_header has been freed */ > > + ro_header = NULL; > > + prog = orig_prog; > > goto out_off; > > } > > - bpf_jit_binary_lock_ro(header); > > + /* > > + * The instructions have now been copied to the ROX region from > > + * where they will execute. Now the data cache has to be cleaned to > > + * the PoU and the I-cache has to be invalidated for the VAs. > > + */ > > + bpf_flush_icache(ro_header, ctx.ro_image + ctx.idx); > > } else { > > jit_data->ctx = ctx; > > - jit_data->image = image_ptr; > > + jit_data->ro_image = ro_image_ptr; > > jit_data->header = header; > > + jit_data->ro_header = ro_header; > > } > > - prog->bpf_func = (void *)ctx.image; > > + > > + prog->bpf_func = (void *)ctx.ro_image; > > prog->jited = 1; > > prog->jited_len = prog_size; > > > > @@ -1714,6 +1766,14 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog) > > bpf_jit_prog_release_other(prog, prog == orig_prog ? > > tmp : orig_prog); > > return prog; > > + > > +out_free_hdr: > > + if (header) { > > + bpf_arch_text_copy(&ro_header->size, &header->size, > > + sizeof(header->size)); > > + bpf_jit_binary_pack_free(ro_header, header); > > + } > > + goto out_off; > > } > > > > bool bpf_jit_supports_kfunc_call(void) > > @@ -1721,6 +1781,13 @@ bool bpf_jit_supports_kfunc_call(void) > > return true; > > } > > > > +void *bpf_arch_text_copy(void *dst, void *src, size_t len) > > +{ > > + if (!aarch64_insn_copy(dst, src, len)) > > + return ERR_PTR(-EINVAL); > > + return dst; > > +} > > + > > u64 bpf_jit_alloc_exec_limit(void) > > { > > return VMALLOC_END - VMALLOC_START; > > @@ -2359,3 +2426,27 @@ bool bpf_jit_supports_exceptions(void) > > */ > > return true; > > } > > + > > +void bpf_jit_free(struct bpf_prog *prog) > > +{ > > + if (prog->jited) { > > + struct arm64_jit_data *jit_data = prog->aux->jit_data; > > + struct bpf_binary_header *hdr; > > + > > + /* > > + * If we fail the final pass of JIT (from jit_subprogs), > > + * the program may not be finalized yet. Call finalize here > > + * before freeing it. > > + */ > > + if (jit_data) { > > + bpf_arch_text_copy(&jit_data->ro_header->size, &jit_data->header->size, > > + sizeof(jit_data->header->size)); > > + kfree(jit_data); > > + } > > + hdr = bpf_jit_binary_pack_hdr(prog); > > + bpf_jit_binary_pack_free(hdr, NULL); > > + WARN_ON_ONCE(!bpf_prog_kallsyms_verify_off(prog)); > > + } > > + > > + bpf_prog_unlock_free(prog); > > +} > > ------------------------------------------------------------------------------- > > > > > > Git bisection log: > > > > ------------------------------------------------------------------------------- > > git bisect start > > # good: [67be068d31d423b857ffd8c34dbcc093f8dfff76] Merge tag 'vfs-6.8-release.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs > > git bisect good 67be068d31d423b857ffd8c34dbcc093f8dfff76 > > # bad: [1843e16d2df9d98427ef8045589571749d627cf7] Add linux-next specific files for 20240307 > > git bisect bad 1843e16d2df9d98427ef8045589571749d627cf7 > > # bad: [1a0a33e22e715a4cc7bb2709cfda8e83b8c756b2] Merge branch 'main' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git > > git bisect bad 1a0a33e22e715a4cc7bb2709cfda8e83b8c756b2 > > # good: [5a0d6b0465ab18fefa8abc9afbabce19e7de2fe5] Merge branch 'nfsd-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux > > git bisect good 5a0d6b0465ab18fefa8abc9afbabce19e7de2fe5 > > # good: [a5fcf74d80bec9948701ff0f7529ae96a0c4a41c] inet: annotate data-races around ifa->ifa_valid_lft > > git bisect good a5fcf74d80bec9948701ff0f7529ae96a0c4a41c > > # good: [7aaab3e1fcee995b70d344687fa0f33b0b9d33f7] Merge branch 'hwmon-next' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git > > git bisect good 7aaab3e1fcee995b70d344687fa0f33b0b9d33f7 > > # good: [dfa2c103738019033bad44d8be7919ad8bc19dd6] Merge branch 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git > > git bisect good dfa2c103738019033bad44d8be7919ad8bc19dd6 > > # bad: [564ae6794ec5f050bb6df4446820777e7253f960] mptcp: get addr in userspace pm list > > git bisect bad 564ae6794ec5f050bb6df4446820777e7253f960 > > # good: [2c21a0f67c8ce334b8a58332e8c2d71694bef0ab] Merge branch 'Support PTR_MAYBE_NULL for struct_ops arguments.' > > git bisect good 2c21a0f67c8ce334b8a58332e8c2d71694bef0ab > > # bad: [4ab597d2962195ca4f01a429f9b2ea87ee684be3] net: bareudp: Remove generic .ndo_get_stats64 > > git bisect bad 4ab597d2962195ca4f01a429f9b2ea87ee684be3 > > # good: [dfe6625df48ec54c6dc9b86d361f26962d09de88] bpf: introduce in_sleepable() helper > > git bisect good dfe6625df48ec54c6dc9b86d361f26962d09de88 > > # bad: [f2e81192e07e87897ff1296c96775eceea8f582a] bpftool: Add an example for struct_ops map and shadow type. > > git bisect bad f2e81192e07e87897ff1296c96775eceea8f582a > > # bad: [1dad391daef129e01e28206b8d586608ff026548] bpf, arm64: use bpf_prog_pack for memory management > > git bisect bad 1dad391daef129e01e28206b8d586608ff026548 > > # good: [22fc0e80aeb5c0c1377e6c02d7248f8fbf5df7fc] bpf, arm64: support exceptions > > git bisect good 22fc0e80aeb5c0c1377e6c02d7248f8fbf5df7fc > > # good: [451c3cab9a65e656c3b3d106831fc02d56b8c34a] arm64: patching: implement text_poke API > > git bisect good 451c3cab9a65e656c3b3d106831fc02d56b8c34a > > # first bad commit: [1dad391daef129e01e28206b8d586608ff026548] bpf, arm64: use bpf_prog_pack for memory management > > ------------------------------------------------------------------------------- > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > > Groups.io Links: You receive all messages sent to this group. > > View/Reply Online (#52295): https://groups.io/g/kernelci-results/message/52295 > > Mute This Topic: https://groups.io/mt/104790392/1131744 > > Group Owner: kernelci-results+owner@groups.io > > Unsubscribe: https://groups.io/g/kernelci-results/unsub [broonie@kernel.org] > > -=-=-=-=-=-=-=-=-=-=-=- > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: next/master bisection: baseline.login on qemu_arm64-virt-gicv3-uefi 2024-03-07 18:16 ` Song Liu @ 2024-03-07 18:34 ` Mark Brown 2024-03-07 19:02 ` Puranjay Mohan 0 siblings, 1 reply; 6+ messages in thread From: Mark Brown @ 2024-03-07 18:34 UTC (permalink / raw) To: Song Liu Cc: Puranjay Mohan, Catalin Marinas, Alexei Starovoitov, Will Deacon, kernelci-results, bot, linux-arm-kernel, linux-mm, bpf, linux-next [-- Attachment #1: Type: text/plain, Size: 603 bytes --] On Thu, Mar 07, 2024 at 10:16:21AM -0800, Song Liu wrote: > On Thu, Mar 7, 2024 at 8:36 AM Mark Brown <broonie@kernel.org> wrote: > > The KernelCI bisection bot found a boot regression n today's -next on > > qemu arm64 UEFI platforms with 64K pages which was bisected to commit > > 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management"). > > We OOM quite early in boot: > IIUC, 64kB pages means 512MB PMD. I think that's indeed too big. We > will need some logic to limit such cases. These qemu instances are only configured with 1G of RAM so that's rather large indeed. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: next/master bisection: baseline.login on qemu_arm64-virt-gicv3-uefi 2024-03-07 18:34 ` Mark Brown @ 2024-03-07 19:02 ` Puranjay Mohan 2024-03-07 23:00 ` Song Liu 0 siblings, 1 reply; 6+ messages in thread From: Puranjay Mohan @ 2024-03-07 19:02 UTC (permalink / raw) To: Mark Brown Cc: Song Liu, Catalin Marinas, Alexei Starovoitov, Will Deacon, kernelci-results, bot, linux-arm-kernel, linux-mm, bpf, linux-next On Thu, Mar 7, 2024 at 7:34 PM Mark Brown <broonie@kernel.org> wrote: > > On Thu, Mar 07, 2024 at 10:16:21AM -0800, Song Liu wrote: > > On Thu, Mar 7, 2024 at 8:36 AM Mark Brown <broonie@kernel.org> wrote: > > > > The KernelCI bisection bot found a boot regression n today's -next on > > > qemu arm64 UEFI platforms with 64K pages which was bisected to commit > > > 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management"). > > > We OOM quite early in boot: > > > IIUC, 64kB pages means 512MB PMD. I think that's indeed too big. We > > will need some logic to limit such cases. As far as I understand, we need the prog pack to be PMD sized so it is allocated as a huge page and if we limit this then vmalloc() will not allocate a huge page and the performance benefit will be lost. > > These qemu instances are only configured with 1G of RAM so that's rather > large indeed. I was able to reproduce this without UEFI as well, I used 600MB in place of 1G. Prog pack tries to allocate 512 MB and this causes the OOM panic. Can we implement this in a way where if the memory can't be allocated then we fallback to allocating less memory rather than panicking. I don't know enough memory management to know how it would be done. Thanks, Puranjay ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: next/master bisection: baseline.login on qemu_arm64-virt-gicv3-uefi 2024-03-07 19:02 ` Puranjay Mohan @ 2024-03-07 23:00 ` Song Liu 2024-03-08 12:12 ` Puranjay Mohan 0 siblings, 1 reply; 6+ messages in thread From: Song Liu @ 2024-03-07 23:00 UTC (permalink / raw) To: Puranjay Mohan Cc: Mark Brown, Catalin Marinas, Alexei Starovoitov, Will Deacon, kernelci-results, bot, linux-arm-kernel, linux-mm, bpf, linux-next On Thu, Mar 7, 2024 at 11:02 AM Puranjay Mohan <puranjay12@gmail.com> wrote: > > On Thu, Mar 7, 2024 at 7:34 PM Mark Brown <broonie@kernel.org> wrote: > > > > On Thu, Mar 07, 2024 at 10:16:21AM -0800, Song Liu wrote: > > > On Thu, Mar 7, 2024 at 8:36 AM Mark Brown <broonie@kernel.org> wrote: > > > > > > The KernelCI bisection bot found a boot regression n today's -next on > > > > qemu arm64 UEFI platforms with 64K pages which was bisected to commit > > > > 1dad391daef1 ("bpf, arm64: use bpf_prog_pack for memory management"). > > > > We OOM quite early in boot: > > > > > IIUC, 64kB pages means 512MB PMD. I think that's indeed too big. We > > > will need some logic to limit such cases. > > As far as I understand, we need the prog pack to be PMD sized so it is > allocated as a huge page > and if we limit this then vmalloc() will not allocate a huge page and > the performance benefit will be lost. bpf_prog_pack gives benefits without using PMD pages. For arm64 with 64kB page, even bpf_prog_pack of 64kB can fit multiple bpf programs in it. OTOH, 512MB is really big. How about we do something like the following? Thanks, Song diff --git i/kernel/bpf/core.c w/kernel/bpf/core.c index 9ee4536d0a09..1fe05c280e31 100644 --- i/kernel/bpf/core.c +++ w/kernel/bpf/core.c @@ -888,7 +888,15 @@ static LIST_HEAD(pack_list); * CONFIG_MMU=n. Use PAGE_SIZE in these cases. */ #ifdef PMD_SIZE -#define BPF_PROG_PACK_SIZE (PMD_SIZE * num_possible_nodes()) + /* PMD_SIZE is really big for some archs. It doesn't make sense to + * reserve too much memory in one allocation. Cap BPF_PROG_PACK_SIZE to + * 2MiB * num_possible_nodes(). + */ + #if PMD_SIZE <= (1 << 21) + #define BPF_PROG_PACK_SIZE (PMD_SIZE * num_possible_nodes()) + #else + #define BPF_PROG_PACK_SIZE ((1 << 21) * num_possible_nodes()) + #endif #else #define BPF_PROG_PACK_SIZE PAGE_SIZE #endif ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: next/master bisection: baseline.login on qemu_arm64-virt-gicv3-uefi 2024-03-07 23:00 ` Song Liu @ 2024-03-08 12:12 ` Puranjay Mohan 0 siblings, 0 replies; 6+ messages in thread From: Puranjay Mohan @ 2024-03-08 12:12 UTC (permalink / raw) To: Song Liu Cc: Mark Brown, Catalin Marinas, Alexei Starovoitov, Will Deacon, kernelci-results, bot, linux-arm-kernel, linux-mm, bpf, linux-next Hi Song, > > bpf_prog_pack gives benefits without using PMD pages. For arm64 > with 64kB page, even bpf_prog_pack of 64kB can fit multiple bpf > programs in it. OTOH, 512MB is really big. > > How about we do something like the following? > > Thanks, > Song > > diff --git i/kernel/bpf/core.c w/kernel/bpf/core.c > index 9ee4536d0a09..1fe05c280e31 100644 > --- i/kernel/bpf/core.c > +++ w/kernel/bpf/core.c > @@ -888,7 +888,15 @@ static LIST_HEAD(pack_list); > * CONFIG_MMU=n. Use PAGE_SIZE in these cases. > */ > #ifdef PMD_SIZE > -#define BPF_PROG_PACK_SIZE (PMD_SIZE * num_possible_nodes()) > + /* PMD_SIZE is really big for some archs. It doesn't make sense to > + * reserve too much memory in one allocation. Cap BPF_PROG_PACK_SIZE to > + * 2MiB * num_possible_nodes(). > + */ > + #if PMD_SIZE <= (1 << 21) > + #define BPF_PROG_PACK_SIZE (PMD_SIZE * num_possible_nodes()) > + #else > + #define BPF_PROG_PACK_SIZE ((1 << 21) * num_possible_nodes()) > + #endif > #else > #define BPF_PROG_PACK_SIZE PAGE_SIZE > #endif I have sent a patch with the above: https://lore.kernel.org/all/20240308120712.88122-1-puranjay12@gmail.com/ Thanks for helping with this. I have tested that this patch fixes this issue. Thanks, Puranjay ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-03-08 12:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <65e9e748.a70a0220.606f7.53c0@mx.google.com>
2024-03-07 16:36 ` next/master bisection: baseline.login on qemu_arm64-virt-gicv3-uefi Mark Brown
2024-03-07 18:16 ` Song Liu
2024-03-07 18:34 ` Mark Brown
2024-03-07 19:02 ` Puranjay Mohan
2024-03-07 23:00 ` Song Liu
2024-03-08 12:12 ` Puranjay Mohan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).