[PATCH bpf-next v6 6/7] riscv, bpf: Mixing bpf2bpf and tailcalls
Björn Töpel
bjorn at kernel.org
Thu Jul 9 04:37:27 PDT 2026
Sorry for the delay here -- the bot had me thinking a bit.
On Wed, 8 Jul 2026 at 10:54, Pu Lehui <pulehui at huaweicloud.com> wrote:
...
> > This assumes a fixed number of instructions before the tailcall entry
> > point. When is_subprog is true, the rv_addi() instruction is not emitted,
> > which means the tailcall entry point moves forward by 4 bytes relative to
> > where RV_TAILCALL_OFFSET expects it to be.
> >
> > The tailcall entry is used in emit_bpf_tail_call() when calculating the
> > jump target for the tail call. If RV_TAILCALL_OFFSET doesn't account for
> > the conditional emission, could this cause the wrong entry point to be
> > used when tail calling into subprograms?
>
> This is not an issue, subprog can not be the tailcall callee.
Say, that we have an entry function that does bpf_for_each_map_array()
into a callback cb(). cb() is a subprogram, so no init of TCC. Now,
cb() calls another subprogram that does a tailcall.
The callback to cb() is coming from the kernel, so a6 could have been
clobbered, no? We're entering a subprogram coming from the C ABI. Now,
if the callback calls a subprog that's tail-call reachable, the TCC
can be garbage?
Björn
More information about the linux-riscv
mailing list