From: Kuan-Wei Chiu <visitorckw@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: corbet@lwn.net, skhan@linuxfoundation.org, geert@linux-m68k.org,
daniel@iogearbox.net, eddyz87@gmail.com, memxor@gmail.com,
andrii@kernel.org, gerg@linux-m68k.org, rdunlap@infradead.org,
martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev,
jolsa@kernel.org, emil@etsalapatis.com, ihor.solodrai@linux.dev,
jserv@ccns.ncku.edu.tw, marscheng@google.com,
eleanor15x@gmail.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
bpf@vger.kernel.org, Daniel Palmer <daniel@thingy.jp>
Subject: Re: [PATCH v7] m68k, bpf: Add initial BPF JIT compiler support
Date: Sun, 11 Oct 2026 01:26:07 +0800 [thread overview]
Message-ID: <asp1LyCLB8J5Dh_q@google.com> (raw)
In-Reply-To: <DM199Y25XQ6Q.X5YFLA8I7RSJ@gmail.com>
On Sat, Oct 10, 2026 at 03:16:04PM +0000, Alexei Starovoitov wrote:
> On Mon, Oct 05, 2026 at 06:52 PM Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> > Tested with the test_bpf.ko:
> > test_bpf: Summary: 1061 PASSED, 0 FAILED, [1049/1049 JIT'ed]
> > test_bpf: test_tail_calls: Summary: 10 PASSED, 0 FAILED, [10/10 JIT'ed]
>
> test_bpf.ko doesn't go through the verifier.
> It has no bpf-to-bpf calls and no callbacks.
>
> > Changes in v7:
> > - Size subprog stack frames from stack_depth instead of MAX_BPF_STACK.
> > - Preserve callee's r2 across BPF_PSEUDO_CALL for aggregate returns.
> > - Clean up state on extra_pass failure in bpf_int_jit_compile().
>
> So these are fixes for bot findings in the code that was never run.
> It doesn't work. See below.
>
> [...]
>
> > + emit_16(ctx, 0x4ee8); /* jmp d16(%a0) */
> > + emit_16(ctx, CPU_IS_COLDFIRE ? 48 : 44);
>
> When the target prog has subprogs its prologue is the is_func flavor.
> It's 110 bytes, and 44 is in the middle of
> move.l %d0, BPF_R2_LO(%fp). The cpu executes 0xfff0.
>
> > +static void build_prologue(struct jit_ctx *ctx)
> > +{
> > + int bpf_stack = ctx->prog->is_func ?
> > + round_up(ctx->prog->aux->stack_depth, 4) : MAX_BPF_STACK;
>
> stack_depth can be more than MAX_BPF_STACK.
> may_goto adds 8 bytes on top of what the prog uses.
> See stack_depth_extra in bpf_do_misc_fixups().
> When the prog uses 512 bytes the counter is at r10 - 520.
> That's where movem.l saved %d4 and %d5, so the C caller of the prog
> gets them back corrupted.
> The target of a tail call reuses the frame, so every frame needs
> that extra space.
>
> > + if (ctx->prog->is_func) {
> > + const s8 arg_regs[] = { BPF_REG_1, BPF_REG_2, BPF_REG_3, BPF_REG_4, BPF_REG_5 };
> > +
> > + for (i = 0; i < 5; i++) {
> > + int offset = 8 + i * 8;
>
> jit_subprogs() sets is_func for func[0] too, which is the main prog.
> It's called from C as bpf_func(ctx, insnsi), so 8(%fp) is ctx and
> 12(%fp) is insnsi. This loop makes R1 = (u64)ctx << 32 | insnsi.
> Every prog that has a subprog or a callback reads its ctx
> out of prog->insnsi.
>
> arm32 and x86-32 JITs don't support bpf-to-bpf calls.
> Drop them from this patch.
> Add them in a follow up when you can run test_progs.
Thanks for the review and the detailed explaination.
My initial patch didn't include subprog support, but I endedd up trying
to deal with it after the bots complained about it.
I'll reject BPF_PSEUDO_CALL, and reserve the extra 8 bytes on the
stack.
Regards,
Kuan-Wei
prev parent reply other threads:[~2026-10-10 17:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 18:52 [PATCH v7] m68k, bpf: Add initial BPF JIT compiler support Kuan-Wei Chiu
2026-10-05 19:07 ` sashiko-bot
2026-10-05 19:48 ` bot+bpf-ci
2026-10-06 13:53 ` Greg Ungerer
2026-10-09 16:32 ` Kuan-Wei Chiu
2026-10-11 14:21 ` Greg Ungerer
2026-10-10 15:16 ` Alexei Starovoitov
2026-10-10 17:26 ` Kuan-Wei Chiu [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=asp1LyCLB8J5Dh_q@google.com \
--to=visitorckw@gmail.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=daniel@iogearbox.net \
--cc=daniel@thingy.jp \
--cc=eddyz87@gmail.com \
--cc=eleanor15x@gmail.com \
--cc=emil@etsalapatis.com \
--cc=geert@linux-m68k.org \
--cc=gerg@linux-m68k.org \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=jserv@ccns.ncku.edu.tw \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=marscheng@google.com \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=rdunlap@infradead.org \
--cc=skhan@linuxfoundation.org \
--cc=song@kernel.org \
--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 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.