Re: [PATCH bpf-next v3 10/20] bpf: Dispatch exception cleanup pads from bpf_throw()

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

On 9/19/26 11:32 PM, bot+bpf-ci@kernel.org wrote:
>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
>> index 5033b934ffd9..0502b9fc4a6d 100644
>> --- a/include/linux/bpf.h
>> +++ b/include/linux/bpf.h
> [ ... ]
>
>> diff --git a/kernel/bpf/exception.c b/kernel/bpf/exception.c
>> index 4859d6484cc8..d4dcbcf4fb25 100644
>> --- a/kernel/bpf/exception.c
>> +++ b/kernel/bpf/exception.c
> [ ... ]
>
>> @@ -499,3 +501,164 @@ int bpf_cleanup_pad_of_call(struct bpf_verifier_env *env, u32 idx)
>>
>>   	return pad ? (int)pad - 1 : -1;
>>   }
>> +
>> +int bpf_cleanup_alloc_info(struct bpf_prog_aux *aux)
>> +{
>> +	if (aux->exc)
>> +		return 0;
>> +	aux->exc = kzalloc_obj(struct bpf_exception_info, GFP_KERNEL_ACCOUNT | __GFP_NOWARN);
>> +	return aux->exc ? 0 : -ENOMEM;
>> +}
>> +
>> +int bpf_cleanup_attach_info(struct bpf_prog_aux *aux, struct bpf_cleanup_info *recs, u32 cnt)
>> +{
>> +	struct bpf_exception_info *exc = aux->exc;
>> +	struct bpf_cleanup_range *ranges;
>> +	u32 i, n_at, *at;
>> +
>> +	if (!cnt) {
>> +		kvfree(recs);
>> +		return 0;
>> +	}
> This isn't a bug, but bpf_cleanup_attach_info()'s only caller already
> returns early when cnt is zero - is the `if (!cnt)` arm here reachable,
> or would dropping it (and letting the caller keep owning that case) make
> the recs ownership easier to follow?

Will drop the above if condition.

>
>> +
>> +	ranges = kvcalloc(cnt, sizeof(*ranges), GFP_KERNEL_ACCOUNT | __GFP_NOWARN);
> [ ... ]
>
>> diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
>> index 558653d3046d..169cbf9f4415 100644
>> --- a/kernel/bpf/fixups.c
>> +++ b/kernel/bpf/fixups.c
> [ ... ]
>
>> @@ -1114,6 +1124,129 @@ static void bpf_restore_subprog_starts(struct bpf_verifier_env *env, u32 *orig_s
>>   	env->subprog_info[env->subprog_cnt].start = env->prog->len;
>>   }
>>
>> +static int cleanup_pad_body_for_subprog(struct bpf_verifier_env *env, struct bpf_prog *sub,
>> +					u32 start, u32 end)
>> +{
>> +	unsigned long *bits;
>> +	u32 i, cnt = 0;
>> +
>> +	for (i = start; i < end; i++)
>> +		if (env->insn_aux_data[i].in_cleanup_pad)
>> +			cnt++;
>> +	if (!cnt)
>> +		return 0;
>> +
>> +	bits = bitmap_zalloc(end - start, GFP_KERNEL_ACCOUNT | __GFP_NOWARN);
>> +	if (!bits)
>> +		return -ENOMEM;
>> +
>> +	for (i = start; i < end; i++)
>> +		if (env->insn_aux_data[i].in_cleanup_pad)
>> +			__set_bit(i - start, bits);
>> +
>> +	sub->aux->exc->pad_body = bits;
>> +	sub->aux->exc->nr_pad_body = end - start;
>> +	return 0;
>> +}
> This isn't a bug, but would naming this field after the bitmap size
> rather than nr_pad_body make it clearer that it is the bit count and not
> the number of pad-body instructions, given the nr_throw_at /
> nr_resume_at siblings are true counts?

Will rename to pad_body_bits.

>
> [ ... ]
>
>
> ---
> 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/35492765538