Re: [PATCH bpf-next v8 2/2] bpf: Reject programs with inlined helpers if JIT is not available

[Eduard Zingerman <eddyz87@gmail.com>]

On Tue, 2026-07-07 at 10:03 +0800, Leon Hwang wrote:
> On 7/7/26 05:41, Eduard Zingerman wrote:
> > On Mon, 2026-07-06 at 12:00 +0800, Tiezhu Yang wrote:
> > > When an architecture (such as LoongArch, ARM64, and RISC-V) implements
> > > bpf_jit_inlines_helper_call(), the verifier skips rewriting the helper
> > > call offset (insn->imm) during the bpf_do_misc_fixups() phase, because
> > > the helper is expected to be inlined by the JIT compiler. As a result,
> > > insn->imm remains as the raw helper enum ID.
> > > 
> > > However, if JIT is disabled at runtime (net.core.bpf_jit_enable=0) or
> > > if the JIT compilation later dynamically fails (e.g., due to OOM), the
> > > core BPF subsystem falls back to the BPF interpreter.
> > > 
> > > When the interpreter executes (__bpf_call_base + insn->imm) with the
> > > unpatched raw helper ID, it jumps into an unaligned invalid address
> > > space, triggering an instruction alignment fault or a memory access
> > > panic.
> > > 
> > > Fix this by setting 'jit_required' to 1 when helper call rewriting is
> > > skipped for JIT inlining. Loading will be rejected early with -EINVAL
> > > if JIT is disabled, or safely rejected with -ENOTSUPP during runtime
> > > selection if JIT compilation dynamically fails, effectively preventing
> > > the kernel panic.
> > > 
> > > Fixes: 2ddec2c80b44 ("riscv, bpf: inline bpf_get_smp_processor_id()")
> > > Suggested-by: Alexei Starovoitov <ast@kernel.org>
> > > Suggested-by: KaFai Wan <kafai.wan@linux.dev>
> > > Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> > > ---
> > 
> > Sorry, I'm late to the party.
> > As far as I understand, the patch #1 doesn't really change anything functionally,
> > it just adds the flag, right?
> > 
> > As for the patch #2 and looking at the helpers that jits currently inline:
> > - bpf_get_smp_processor_id (implemented as a function in the helpers.c)
> > - bpf_get_current_task (implemented as a function in the bpf_trace.c)
> > - bpf_get_current_task_btf (implemented as a function in the bpf_trace.c)
> > 
> > It is perfectly fine to call these as helper functions even if jit is
> > not available. But this was broken since:
> > 2ddec2c80b44 ("riscv, bpf: inline bpf_get_smp_processor_id()")
> > from May 2024, so I guess nobody really cares?
> 
> 
> Vincent Thiberville reported an interpreter fallback issue for the
> internal BPF_ADDR_PERCPU insn [1].

As far as I understand, [1] is caused by map lookup helper inlining,
bpf_jit_inlines_helper_call() is unrelated this mechanism and only
covers that three helpers I listed above.

> And, I was trying to fix assorted interpreter fallback issues [2].
> 
> I think it is worth fixing the interpreter fallback issue for the JIT
> inlineable helper.

Meaning that you'd prefer the bpf_get_smp_processor_id() and co to
work correctly w/o JIT, do I understand you correctly?

> 
> [1]
> https://lore.kernel.org/bpf/MR1P264MB331494502C9D13D8A9EAFB99B7E82@MR1P264MB3314.FRAP264.PROD.OUTLOOK.COM/
> [2] https://lore.kernel.org/bpf/20260626154330.33619-1-leon.hwang@linux.dev/
> 
> Thanks,
> Leon
> 
> > 
> > Imo, the simplest and least intrusive fix is to add a wrapper in the
> > verifier.c that would call both bpf_jit_inlines_helper_call() and
> > check if the jit is enabled and use that wrapper instead of direct
> > calls to bpf_jit_inlines_helper_call().
> > 
> > Anyway, since this was broken all-along, might as well land as-is.
> > Thoughts?
> > 
> > [...]