Re: [PATCH v2 3/4] LoongArch: BPF: Refactor jump offset calculation in tail call

[Tiezhu Yang <yangtiezhu@loongson.cn>]

On 2026/7/6 下午12:43, bot+bpf-ci@kernel.org wrote:
>> In emit_bpf_tail_call(), the macro-based jmp_offset calculation relies
>> on a fragile prediction equation: "tc_ninsn - (ctx->idx - idx0)". This
>> calculation model utilizes tc_ninsn from the previous pass to estimate
>> the remaining stride of the active tail call code block.

...

> 
> This looks like a fix for wrong branch offsets in the tail call path.
> Should it carry a Fixes: tag?  The tc_ninsn macro and the
> 
>    tc_ninsn = insn ? ctx->offset[insn+1] - ctx->offset[insn] : ctx->offset[0];
> 
> calculation being removed here were introduced by:
> 
>    Fixes: cd39d9e6b7e4 ("LoongArch: BPF: Fix jump offset calculation in tailcall")
> 
> This isn't a bug, but could the changelog be tightened?  Phrases such as
> "rock-solid target label", "deterministic arithmetic model",
> "initialization bottleneck", "eBPF business instruction" and "all code
> size dimensions" read as fairly ornate for an offset-formula refactor.
> 
> Could it just state that the old macro derived jmp_offset from a stale
> prior-pass stride while the new form anchors on ctx->offset[insn + 1],
> with the ctx->image == NULL guard avoiding a false 16-bit range abort
> during size estimation?

OK, I will add the Fixes tag and trim the commit message in v3.

Thanks,
Tiezhu