From: Eduard Zingerman <eddyz87@gmail.com>
To: Xu Kuohai <xukuohai@huaweicloud.com>,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: "Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Martin KaFai Lau" <martin.lau@linux.dev>,
"Yonghong Song" <yonghong.song@linux.dev>,
"Puranjay Mohan" <puranjay@kernel.org>,
"Anton Protopopov" <a.s.protopopov@gmail.com>,
"Alexis Lothoré" <alexis.lothore@bootlin.com>,
"Shahab Vahedi" <list+bpf@vahedi.org>,
"Russell King" <linux@armlinux.org.uk>,
"Tiezhu Yang" <yangtiezhu@loongson.cn>,
"Hengqi Chen" <hengqi.chen@gmail.com>,
"Johan Almbladh" <johan.almbladh@anyfinetworks.com>,
"Paul Burton" <paulburton@kernel.org>,
"Hari Bathini" <hbathini@linux.ibm.com>,
"Christophe Leroy" <chleroy@kernel.org>,
"Naveen N Rao" <naveen@kernel.org>,
"Luke Nelson" <luke.r.nels@gmail.com>,
"Xi Wang" <xi.wang@gmail.com>, "Björn Töpel" <bjorn@kernel.org>,
"Pu Lehui" <pulehui@huawei.com>,
"Ilya Leoshkevich" <iii@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"David S . Miller" <davem@davemloft.net>,
"Wang YanQing" <udknight@gmail.com>
Subject: Re: [PATCH bpf-next v9 1/5] bpf: Move constants blinding out of arch-specific JITs
Date: Fri, 13 Mar 2026 18:29:33 -0700 [thread overview]
Message-ID: <4e4c3be9bfca85c5343834b5d6b1d6283fd6a1f5.camel@gmail.com> (raw)
In-Reply-To: <20260312170255.3427799-2-xukuohai@huaweicloud.com>
On Fri, 2026-03-13 at 01:02 +0800, Xu Kuohai wrote:
[...]
> diff --git a/arch/arc/net/bpf_jit_core.c b/arch/arc/net/bpf_jit_core.c
> index 1421eeced0f5..973ceae48675 100644
> --- a/arch/arc/net/bpf_jit_core.c
> +++ b/arch/arc/net/bpf_jit_core.c
[...]
> @@ -229,12 +211,19 @@ static void jit_ctx_cleanup(struct jit_context *ctx)
> ctx->bpf2insn_valid = false;
>
> /* Freeing "bpf_header" is enough. "jit.buf" is a sub-array of it. */
> - if (!ctx->success && ctx->bpf_header) {
> - bpf_jit_binary_free(ctx->bpf_header);
> - ctx->bpf_header = NULL;
> - ctx->jit.buf = NULL;
> - ctx->jit.index = 0;
> - ctx->jit.len = 0;
> + if (!ctx->success) {
> + if (ctx->bpf_header) {
> + bpf_jit_binary_free(ctx->bpf_header);
> + ctx->bpf_header = NULL;
> + ctx->jit.buf = NULL;
> + ctx->jit.index = 0;
> + ctx->jit.len = 0;
> + }
> + if (ctx->is_extra_pass) {
Nit: The idea is that for !ctx->is_extra_pass
ctx->prog->bpf_func != NULL only when ctx->success is true, right?
Maybe just drop the condition?
> + ctx->prog->bpf_func = NULL;
> + ctx->prog->jited = 0;
> + ctx->prog->jited_len = 0;
> + }
> }
>
> ctx->emit = false;
> diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
> index deeb8f292454..e6b1bb2de627 100644
> --- a/arch/arm/net/bpf_jit_32.c
> +++ b/arch/arm/net/bpf_jit_32.c
> @@ -2144,9 +2144,7 @@ bool bpf_jit_needs_zext(void)
>
> struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
> {
> - struct bpf_prog *tmp, *orig_prog = prog;
> struct bpf_binary_header *header;
> - bool tmp_blinded = false;
> struct jit_ctx ctx;
> unsigned int tmp_idx;
> unsigned int image_size;
The code in arch/arc is modified to do `... ctx->prog->jited = 0; ...`,
but for arm32 there is no such modification. Why is that so?
[...]
> diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
> index adf84962d579..cd5a72fff500 100644
> --- a/arch/arm64/net/bpf_jit_comp.c
> +++ b/arch/arm64/net/bpf_jit_comp.c
> @@ -2009,14 +2009,12 @@ struct arm64_jit_data {
[...]
> @@ -2245,13 +2211,15 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
> kfree(jit_data);
> prog->aux->jit_data = NULL;
> }
> -out:
> - if (tmp_blinded)
> - bpf_jit_prog_release_other(prog, prog == orig_prog ?
> - tmp : orig_prog);
> +
> return prog;
>
> out_free_hdr:
> + if (extra_pass) {
> + prog->bpf_func = NULL;
> + prog->jited = 0;
> + prog->jited_len = 0;
> + }
Just for my understanding, is the following correct?
- Previously, a call bpf_jit_blind_constants() always cloned the prog.
- Jits only set prog->jited to true upon successful compilation.
- On error exit jits restored the original prog with it's prog->jited == 0.
What happened in case of an extra pass?
I'd expect that in case of an extra pass prog->jited would be true
even before program is cloned by blind_constants() (and that's what
arc code uses to figure out if the current pass is an extra pass).
If so, old code would preserve prog->jited as true even in case of
extra pass failure. Is that true or am I confused?
Just trying to understand why this patch has to deal with the above
snippet at all. In case it is indeed necessary, it seems the logic
should be similar for all jits, is there a way to push this snippet to
some common code? E.g. in verifier.c where the extra pass is initiated.
[...]
next prev parent reply other threads:[~2026-03-14 1:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-12 17:02 [-next v9 0/5] emit ENDBR/BTI instructions for indirect jump targets Xu Kuohai
2026-03-12 17:02 ` [PATCH bpf-next v9 1/5] bpf: Move constants blinding out of arch-specific JITs Xu Kuohai
2026-03-12 17:50 ` bot+bpf-ci
2026-03-13 2:32 ` Xu Kuohai
2026-03-13 9:18 ` Hari Bathini
2026-03-13 9:55 ` Pu Lehui
2026-03-14 1:29 ` Eduard Zingerman [this message]
2026-03-14 4:21 ` Xu Kuohai
2026-03-15 6:05 ` kernel test robot
2026-03-12 17:02 ` [PATCH bpf-next v9 2/5] bpf: Pass bpf_verifier_env to JIT Xu Kuohai
2026-03-12 17:02 ` [PATCH bpf-next v9 3/5] bpf: Add helper to detect indirect jump targets Xu Kuohai
2026-03-12 17:02 ` [PATCH bpf-next v9 4/5] bpf, x86: Emit ENDBR for " Xu Kuohai
2026-03-13 10:15 ` Leon Hwang
2026-03-14 6:48 ` Xu Kuohai
2026-03-14 13:35 ` Leon Hwang
2026-03-23 13:39 ` Xu Kuohai
2026-03-12 17:02 ` [PATCH bpf-next v9 5/5] bpf, arm64: Emit BTI for indirect jump target Xu Kuohai
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=4e4c3be9bfca85c5343834b5d6b1d6283fd6a1f5.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=a.s.protopopov@gmail.com \
--cc=alexis.lothore@bootlin.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=chleroy@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=gor@linux.ibm.com \
--cc=hbathini@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hengqi.chen@gmail.com \
--cc=iii@linux.ibm.com \
--cc=johan.almbladh@anyfinetworks.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=list+bpf@vahedi.org \
--cc=luke.r.nels@gmail.com \
--cc=martin.lau@linux.dev \
--cc=naveen@kernel.org \
--cc=paulburton@kernel.org \
--cc=pulehui@huawei.com \
--cc=puranjay@kernel.org \
--cc=udknight@gmail.com \
--cc=xi.wang@gmail.com \
--cc=xukuohai@huaweicloud.com \
--cc=yangtiezhu@loongson.cn \
--cc=yonghong.song@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®