Re: [PATCH bpf-next 13/20] libbpf: Resolve the compiler's _Unwind_Resume to the kernel's kfunc

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

On 9/17/26 12:00 AM, bot+bpf-ci@kernel.org wrote:
>> diff --git tools/lib/bpf/libbpf.c tools/lib/bpf/libbpf.c
>> index 613afae265199..ea1c09fa37939 100644
>> --- tools/lib/bpf/libbpf.c
>> +++ tools/lib/bpf/libbpf.c
>> @@ -8346,6 +8346,15 @@ static void fixup_verifier_log(struct bpf_program *prog, char *buf, size_t buf_s
>>   	}
>>   }
>>
>> +/* LLVM terminates a cleanup landing pad with a call to _Unwind_Resume, the
>> + * base unwind ABI's entry point for carrying an unwind on once a frame's
>> + * cleanups have run. The kernel knows it as bpf_unwind_resume.
>> + */
>> +static const char *kern_extern_name(const char *name)
>> +{
>> +	return strcmp(name, "_Unwind_Resume") ? name : "bpf_unwind_resume";
>> +}
>> +
>>   static int bpf_program_record_relos(struct bpf_program *prog)
>>   {
>>   	struct bpf_object *obj = prog->obj;
> Is the kern_extern_name() mapping applied on the light skeleton load
> path?
>
> Looking at bpf_program_record_relos() below kern_extern_name(), the
> RELO_EXTERN_CALL case records ext->name directly without calling
> kern_extern_name():
>
> static int bpf_program_record_relos(struct bpf_program *prog)
> {
>      ...
>      case RELO_EXTERN_CALL:
>          bpf_gen__record_extern(obj->gen_loader, ext->name,
>                                 ext->is_weak, false, false, BTF_KIND_FUNC,
>                                 relo->insn_idx);
>          break;
>      ...
> }
>
> This means the generated loader program would ask the kernel for
> BTF_KIND_FUNC '_Unwind_Resume', which doesn't exist in vmlinux BTF. The
> kernel only knows bpf_unwind_resume per BTF_ID_FLAGS(func,
> bpf_unwind_resume) in kernel/bpf/helpers.c.
>
> For comparison, the direct BPF_PROG_LOAD path does use the mapping:
>
> bpf_object__resolve_ksym_func_btf_id() calls kern_extern_name() at
> libbpf.c:8824, but that resolution is deliberately skipped when
> obj->gen_loader is set:
>
> bpf_object__resolve_ksyms_btf_id() {
>      ...
>      if (obj->gen_loader) {
>          ext->is_set = true;
>          ext->ksym.kernel_btf_obj_fd = 0;
>          ext->ksym.kernel_btf_id = 0;
>          continue;
>      }
>      ...
> }
>
> On the light skeleton path, bpf_btf_find_by_name_kind() would return
> -ESRCH for '_Unwind_Resume', causing emit_check_err() to jump to cleanup
> and fail the load. If the extern were weak, insn->imm/off would be
> stored as 0, which the verifier would reject as an invalid kfunc call.
>
> The test added later in the series
> (selftests/bpf/progs/exceptions_cleanup_light.c) writes 'call
> bpf_unwind_resume' directly in inline asm, so it uses the kernel name
> and never exercises the mapping.

Indeed, later patch in selftests/bpf/progs/exceptions_cleanup_light.c
fixed the issue with bpf_undiwn_resume properly. So this is not really
a bug. But we can do better than this. We can change from ext->name to
bpf_unwind_resume in file selftests/bpf/progs/exceptions_cleanup_light.c
for this patch. This will make things easier to understand.

>
>> @@ -8807,17 +8816,19 @@ static int bpf_object__resolve_ksym_func_btf_id(struct bpf_object *obj,
>>   	struct module_btf *mod_btf = NULL;
>>   	const struct btf_type *kern_func;
>>   	struct btf *kern_btf = NULL;
>> +	const char *kern_name;
>>   	int ret;
>>
>>   	local_func_proto_id = ext->ksym.type_id;
>>
>> -	kfunc_id = find_ksym_btf_id(obj, ext->essent_name ?: ext->name, BTF_KIND_FUNC, &kern_btf,
>> -				    &mod_btf);
>> +	kern_name = kern_extern_name(ext->essent_name ?: ext->name);
>> +
>> +	kfunc_id = find_ksym_btf_id(obj, kern_name, BTF_KIND_FUNC, &kern_btf, &mod_btf);
>>   	if (kfunc_id < 0) {
>>   		if (kfunc_id == -ESRCH && ext->is_weak)
>>   			return 0;
>>   		pr_warn("extern (func ksym) '%s': not found in kernel or module BTFs\n",
>> -			ext->name);
>> +			strcmp(kern_name, "bpf_unwind_resume") ? ext->name : kern_name);
>>   		return kfunc_id;
>>   	}
>
> ---
> 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/35188619605