Re: [PATCH bpf-next v3] bpf: arm64: Fix panic due to missing BTI at indirect jump targets

[Xu Kuohai]

On 12/31/2025 2:20 AM, Alexei Starovoitov wrote:
> On Fri, Dec 26, 2025 at 11:49 PM Xu Kuohai <xukuohai@xxxxxxxxxxxxxxx> wrote:
> > From: Xu Kuohai <xukuohai@xxxxxxxxxx>
> >
> > When BTI is enabled, the indirect jump selftest triggers BTI exception:
> >
> > Internal error: Oops - BTI: 0000000036000003 [#1]  SMP
> > ...
> > Call trace:
> >   bpf_prog_2e5f1c71c13ac3e0_big_jump_table+0x54/0xf8 (P)
> >   bpf_prog_run_pin_on_cpu+0x140/0x464
> >   bpf_prog_test_run_syscall+0x274/0x3ac
> >   bpf_prog_test_run+0x224/0x2b0
> >   __sys_bpf+0x4cc/0x5c8
> >   __arm64_sys_bpf+0x7c/0x94
> >   invoke_syscall+0x78/0x20c
> >   el0_svc_common+0x11c/0x1c0
> >   do_el0_svc+0x48/0x58
> >   el0_svc+0x54/0x19c
> >   el0t_64_sync_handler+0x84/0x12c
> >   el0t_64_sync+0x198/0x19c
> >
> > This happens because no BTI instruction is generated by the JIT for
> > indirect jump targets.
> >
> > Fix it by emitting BTI instruction for every possible indirect jump
> > targets when BTI is enabled. The targets are identified by traversing
> > all instruction arrays of jump table type used by the BPF program,
> > since indirect jump targets can only be read from instruction arrays
> > of jump table type.
>
> earlier you said:
>
> > As Anton noted, even though jump tables are currently the only type
> > of instruction array, users may still create insn_arrays that are not
> > used as jump tables. In such cases, there is no need to emit BTIs.
>
> yes, but it's not worth it to make this micro optimization in JIT.
> If it's in insn_array just emit BTI unconditionally.
> No need to do this filtering.

Hmm, that is what the v1 version does. Please take a look. If it’s okay,
I’ll resend a rebased version.

v1: https://lore.kernel.org/bpf/20251127140318.3944249-1-xukuohai@xxxxxxxxxxxxxxx/

> pw-bot: cr