Re: [PATCH bpf-next v2 12/20] bpf, arm64: Dispatch exception cleanup pads at run time

[Yonghong Song <yonghong.song@linux.dev>]

On 9/17/26 10:44 PM, bot+bpf-ci@kernel.org wrote:
>> diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
>> index 6c04fee468766..560eba305bca2 100644
>> --- a/arch/arm64/net/bpf_jit_comp.c
>> +++ b/arch/arm64/net/bpf_jit_comp.c
> [ ... ]
>
>> @@ -75,7 +76,21 @@ static const int bpf2a64[] = {
>>   	[ARENA_VM_START] = A64_R(28),
>>   };
>>
>> +/* Throw-site spill: the five pairs push_callee_regs() forces on, same size and
>> + * slot order, so arch_bpf_run_cleanup_pad() reads both alike.
>> + */
>> +#define A64_CLEANUP_SPILL_SZ	(5 * 16)
>> +
>> +/*
>> + * Where a landing pad's frame is anchored, since the stack pointer generated
>> + * code normally addresses it through is the walker's inside a pad. bpf2a64[]
>> + * maps nothing to x24, so nothing else in generated code touches it.
>> + */
>> +#define A64_CLEANUP_FP		A64_R(24)
>> +
>>   struct jit_ctx {
>> +	/* Bytes reserved for the throw-site spill; see bpf_cleanup_force_spill(). */
>> +	u32 throw_spill;
>>   	const struct bpf_prog *prog;
>>   	int idx;
>>   	int epilogue_offset;
> This isn't a bug, but would it read better to put throw_spill next to
> stack_size and stack_arg_size, which it is always used with, rather
> than ahead of prog at the head of the struct?

Okay, will do.

>
> [ ... ]
>
>> @@ -1367,6 +1411,7 @@ static int build_insn(const struct bpf_verifier_env *env, const struct bpf_insn
>>   	const s16 off = insn->off;
>>   	const s32 imm = insn->imm;
>>   	const int i = insn - ctx->prog->insnsi;
>> +	const bool in_pad = bpf_cleanup_insn_in_pad(ctx->prog, i);
>>   	const bool is64 = BPF_CLASS(code) == BPF_ALU64 ||
>>   			  BPF_CLASS(code) == BPF_JMP;
>>   	u8 jmp_cond;
>> @@ -1378,9 +1423,14 @@ static int build_insn(const struct bpf_verifier_env *env, const struct bpf_insn
>>   	int ret;
>>   	bool sign_extend;
>>
>> -	if (bpf_insn_is_indirect_target(env, ctx->prog, i))
>> +	if (bpf_insn_is_indirect_target(env, ctx->prog, i) ||
>> +	    bpf_cleanup_insn_is_pad(ctx->prog, i))
>>   		emit_bti(A64_BTI_J, ctx);
>>
>> +	if (bpf_cleanup_insn_is_pad(ctx->prog, i))
>> +		emit(A64_SUB_I(1, A64_CLEANUP_FP, fp,
>> +			       ctx->stack_size + ctx->stack_arg_size), ctx);
>> +
> This isn't a bug, but could the two bpf_cleanup_insn_is_pad() calls
> share a local the way in_pad does, and could the throw-site check
> further down use the existing 'i' instead of recomputing
> insn - ctx->prog->insnsi?

Will do.

>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/35308528711