Re: [PATCH v3 3/5] libbpf: turn relo_core->sym_off unsigned

["Emil Tsalapatis" <emil@etsalapatis.com>]

On Mon Dec 15, 2025 at 11:37 AM EST, bot+bpf-ci wrote:
>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>> index c7c79014d46c..5e66bbc2ab85 100644
>> --- a/tools/lib/bpf/libbpf.c
>> +++ b/tools/lib/bpf/libbpf.c
>> @@ -380,7 +380,7 @@ struct reloc_desc {
>>  		const struct bpf_core_relo *core_relo; /* used when type == RELO_CORE */
>>  		struct {
>>  			int map_idx;
>> -			int sym_off;
>> +			unsigned int sym_off;
>>  			/*
>>  			 * The following two fields can be unionized, as the
>>  			 * ext_idx field is used for extern symbols, and the
>> @@ -763,7 +763,7 @@ struct bpf_object {
>>
>>  	struct {
>>  		struct bpf_program *prog;
>> -		int sym_off;
>> +		unsigned int sym_off;
>>  		int fd;
>>  	} *jumptable_maps;
>>  	size_t jumptable_map_cnt;
>
> The field type change looks correct, but does create_jt_map() defeat
> the purpose of this patch? That function declares a local variable
> "int sym_off" that immediately converts the unsigned field back to
> signed. When sym_off is >= 2GiB (the exact scenario this patch enables),
> the local variable will interpret it as negative, causing incorrect
> behavior in the modulo check, bounds check, and pointer arithmetic that
> follow.
>
>

The jumptable relocations handled by create_jt_map() don't have their
symbol offset artificially inflated they way we do for symbols in the
arena section, so keeping the sym_off signed inside create_jt_map() 
should not cause a problem. We should still change it to handle
sym_off consistently across the codebase.

> ---
> 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/20239524817