From: sashiko-bot@kernel.org
To: "Ramin Moussavi" <ramin.moussavi@yacoub.de>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next] bpf, arm32: build constants inline instead of using a literal pool
Date: Wed, 11 Nov 2026 12:23:46 +0000 [thread overview]
Message-ID: <sashiko-outbox-208972@kernel.org> (raw)
In-Reply-To: <20261111121621.665533-1-ramin.moussavi@yacoub.de>
Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Low] bpf, arm32: non-standard multi-line comment style in
emit_mov_i_no8m()
- [Low] bpf, arm32: unused flags field left in struct jit_ctx
--
commit 04b7597139a2756fa5ffbad42747333b65860a8c
Author: Ramin Moussavi <ramin.moussavi@yacoub.de>
bpf, arm32: build constants inline instead of using a literal pool
This commit replaces the literal pool used for non-imm8m constants on
ARMv5 and ARMv6 with inline MVN/MOV/ORR instruction sequences and removes
the literal pool tracking fields and overflow fallback.
> diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
> index 9ede81afbc50e..d3b5d77450687 100644
> --- a/arch/arm/net/bpf_jit_32.c
> +++ b/arch/arm/net/bpf_jit_32.c
> @@ -130,8 +130,6 @@ enum {
> #define TMP_REG_2 (MAX_BPF_JIT_REG + 1) /* TEMP Register 2 */
> #define TCALL_CNT (MAX_BPF_JIT_REG + 2) /* Tail Call Count */
>
> -#define FLAG_IMM_OVERFLOW (1 << 0)
> -
[ ... ]
> @@ -209,11 +203,6 @@ struct jit_ctx {
> u32 *offsets;
> u32 *target;
> u32 stack_size;
> -#if __LINUX_ARM_ARCH__ < 7
> - u16 epilogue_bytes;
> - u16 imm_count;
> - u32 *imms;
> -#endif
> };
[Severity: Low]
With FLAG_IMM_OVERFLOW removed, is struct jit_ctx's flags member now
unused as well? Nothing else in arch/arm/net/bpf_jit_32.c reads or writes
ctx->flags, so it can be dropped alongside epilogue_bytes, imm_count, and
imms.
[ ... ]
> @@ -469,7 +411,30 @@ static inline int bpf2a32_offset(int bpf_to, int bpf_from,
> static inline void emit_mov_i_no8m(const u8 rd, u32 val, struct jit_ctx *ctx)
> {
> #if __LINUX_ARM_ARCH__ < 7
> - emit(ARM_LDR_I(rd, ARM_PC, imm_offset(val, ctx)), ctx);
> + /* A single MVN if the inverted value is an imm8m, else one
> + * MOV/ORR per non-zero byte -- a byte is always an imm8m.
> + */
[Severity: Low]
This isn't a bug, but BPF code uses the multi-line comment style where
the opening /* sits on its own line and the comment text starts on the
next line.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261111121621.665533-1-ramin.moussavi@yacoub.de?part=1
prev parent reply other threads:[~2026-11-11 12:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 12:16 [PATCH bpf-next] bpf, arm32: build constants inline instead of using a literal pool Ramin Moussavi
2026-11-11 12:23 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-208972@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=ramin.moussavi@yacoub.de \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.