Re: [PATCH bpf-next v4 01/20] bpf: Accept the compiler's exception cleanup table at program load

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

On 9/21/26 2:56 PM, bot+bpf-ci@kernel.org wrote:
>> bpf: Accept the compiler's exception cleanup table at program load
>>
>> LLVM 23 added exception handling support for BPF with the .bpf_cleanup
>> section ([1]). Rust code compiled with panic=unwind runs cleanup code
>> (Drop glue) when bpf_throw() fires, and the LLVM BPF backend emits that
>> section from the landing pads the frontend produced. Plain C cannot
>> generate .bpf_cleanup unless inline asm is used. The Rust compiler does not
>> *properly* support BPF exception handling yet, but the kernel can support
>> the table today, and inline assembly is enough to test it.
>>
>> Add the UAPI to carry the .bpf_cleanup table into the kernel. BPF_PROG_LOAD
>> grows cleanup_info, cleanup_info_cnt and cleanup_info_rec_size, and struct
>> bpf_cleanup_info describes one record as a triple of instruction indices:
>> the half-open call-site range [begin_off, end_off) and the landing_pad_off
>> the frame resumes at. check_cleanup_info() validates the table a program is
>> loaded with, so the rest of the kernel can rely on it.
> This isn't a bug, but since the table is freed at the end of bpf_check()
> and nothing reads env->cleanup_info yet, would it help to say here that
> later patches in the series are the consumers, rather than that the rest
> of the kernel can already rely on it?

Okay, we can say:
   the patches, which follow the CFG walk, the unwind walk and the JITs,
   are its consumers.

>
>> Link: https://github.com/llvm/llvm-project/pull/192164 [1]
>> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
>> diff --git a/kernel/bpf/check_btf.c b/kernel/bpf/check_btf.c
>> index 0e8b3ccc7a5b..17af0a414d74 100644
>> --- a/kernel/bpf/check_btf.c
>> +++ b/kernel/bpf/check_btf.c
>> @@ -407,6 +407,153 @@ static int check_core_relo(struct bpf_verifier_env *env,
>>   	return err;
>>   }
>>
>> +static int cleanup_insn_subprog(struct bpf_verifier_env *env, u32 off)
>> +{
>> +	struct bpf_subprog_info *info;
>> +
>> +	if (off >= env->prog->len)
>> +		return -1;
>> +	info = bpf_find_containing_subprog(env, off);
>> +	return info ? info - env->subprog_info : -1;
>> +}
> This isn't a bug, but would a name like cleanup_off_subprog() or
> insn_subprog_idx() read a little less like an action here, given it
> returns a subprog index?

Will change cleanup_insn_subprog() to cleanup_subprog_of().

>
>> +
>> +#define MIN_BPF_CLEANUP_INFO_SIZE	12
>> +#define MAX_CLEANUP_INFO_REC_SIZE	MAX_FUNCINFO_REC_SIZE
>> +
>> +static int check_cleanup_info(struct bpf_verifier_env *env,
>> +			      const union bpf_attr *attr,
>> +			      bpfptr_t uattr)
>> +{
>> +	u32 krec_size = sizeof(struct bpf_cleanup_info);
>> +	u32 i, nrec, urec_size, min_size, prev_end = 0;
>> +	struct bpf_cleanup_info *krecord;
>> +	bpfptr_t urecord;
>> +	int ret = -EINVAL;
>> +
>> +	nrec = attr->cleanup_info_cnt;
>> +	if (!nrec)
>> +		return 0;
>> +	/* Disjoint ranges, so no more records than instructions. */
>> +	if (nrec > env->prog->len) {
>> +		verbose(env, "cleanup info has %u records for %u instructions\n",
>> +			nrec, env->prog->len);
>> +		return -EINVAL;
>> +	}
>> +
>> +	urec_size = attr->cleanup_info_rec_size;
>> +	if (urec_size < MIN_BPF_CLEANUP_INFO_SIZE ||
>> +	    urec_size > MAX_CLEANUP_INFO_REC_SIZE ||
>> +	    urec_size % sizeof(u32)) {
>> +		verbose(env, "invalid cleanup info rec size %u\n", urec_size);
>> +		return -EINVAL;
>> +	}
>> +
>> +	krecord = kvcalloc(nrec, krec_size, GFP_KERNEL_ACCOUNT | __GFP_NOWARN);
>> +	if (!krecord)
>> +		return -ENOMEM;
>> +
>> +	min_size = min_t(u32, krec_size, urec_size);
>> +	urecord = make_bpfptr(attr->cleanup_info, uattr.is_kernel);
>> +	for (i = 0; i < nrec; i++) {
>> +		struct bpf_cleanup_info *rec = &krecord[i];
>> +		int sb, se, sl;
>> +
>> +		ret = bpf_check_uarg_tail_zero(urecord, krec_size, urec_size);
>> +		if (ret) {
>> +			if (ret == -E2BIG) {
>> +				verbose(env, "nonzero tailing record in cleanup info\n");
>> +				if (copy_to_bpfptr_offset(uattr,
>> +							  offsetof(union bpf_attr,
>> +								   cleanup_info_rec_size),
>> +							  &min_size, sizeof(min_size)))
>> +					ret = -EFAULT;
>> +			}
>> +			goto err_free;
>> +		}
>> +
>> +		if (copy_from_bpfptr(rec, urecord, min_size)) {
>> +			ret = -EFAULT;
>> +			goto err_free;
>> +		}
>> +		bpfptr_add(&urecord, urec_size);
> This isn't a bug, but with this being the fourth copy of the
> rec_size-check / tail-zero / copy_from_bpfptr preamble in this file
> (prepare_btf_func, check_btf_line, check_core_relo and now
> check_cleanup_info), would it be worth pulling the common part into a
> small helper parameterised by the record size and the bpf_attr offset?

I will skip this for now.

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