linux-kernel - Re: [PATCH bpf-next v2 04/13] resolve_btfids: Introduce finalize

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <74fbaa99-024b-4e42-bda0-99ae792d565b@linux.dev>
Date: Tue, 20 Jan 2026 10:35:13 -0800
From: Ihor Solodrai <ihor.solodrai@...ux.dev>
To: Eduard Zingerman <eddyz87@...il.com>, Alexei Starovoitov
 <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>
Cc: Mykyta Yatsenko <yatsenko@...a.com>, Tejun Heo <tj@...nel.org>,
 Alan Maguire <alan.maguire@...cle.com>,
 Benjamin Tissoires <bentiss@...nel.org>, Jiri Kosina <jikos@...nel.org>,
 Amery Hung <ameryhung@...il.com>, bpf@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
 sched-ext@...ts.linux.dev
Subject: Re: [PATCH bpf-next v2 04/13] resolve_btfids: Introduce
 finalize_btf() step

On 1/20/26 10:19 AM, Eduard Zingerman wrote:
> On Tue, 2026-01-20 at 10:11 -0800, Ihor Solodrai wrote:
> 
> [...]
> 
>>>> @@ -1099,12 +1116,22 @@ int main(int argc, const char **argv)
>>>>  	if (obj.efile.idlist_shndx == -1 ||
>>>>  	    obj.efile.symbols_shndx == -1) {
>>>>  		pr_debug("Cannot find .BTF_ids or symbols sections, skip symbols resolution\n");
>>>> -		goto dump_btf;
>>>> +		resolve_btfids = false;
>>>>  	}
>>>>  
>>>> -	if (symbols_collect(&obj))
>>>> +	if (resolve_btfids)
>>>> +		if (symbols_collect(&obj))
>>>> +			goto out;
>>>
>>> Nit: check obj.efile.idlist_shndx and obj.efile.symbols_shndx inside symbols_collect()?
>>>      To avoid resolve_btfids flag and the `goto dump_btf;` below.
>>
>> Hi Eduard, thank you for review.
>>
>> The issue is that in case of .BTF_ids section absent we have to skip
>> some of the steps, specifically:
>>   - symbols_collect()
>>   - sequence between symbols_resolve() and dump_raw_btf_ids()
> 
>> It's not an exit condition, we still have to do load/dump of the BTF.
>>
>> I tried in symbols_collect():
>>
>> 	if (obj.efile.idlist_shndx == -1 || obj.efile.symbols_shndx == -1)
>> 		return 0;
>>
>> But then, we either have to do the same check in symbols_resolve() and
>> co, or maybe store a flag in the struct object.  So I decided it's
>> better to have an explicit flag in the main control flow, instead of
>> hiding it.
> 
> For symbols_resolve() is any special logic necessary?
> I think that `id = btf_id__find(root, str);` will just return NULL for
> every type, thus the whole function would be a noop passing through
> BTF types once.
> 
> symbols_patch() will be a noop, as it will attempt traversing empty roots.
> dump_raw_btf_ids() already returns if there are no .BTF_ids.

Hm... Looks like you're right, those would be noops.

Still, I think it's clearer what steps are skipped with a toplevel
flag.  Otherwise to figure out that those are noops you need to check
every subroutine (as you just did), and a future change may
unintentionally break the expectation of noop creating an unnecessary
debugging session.

And re symbols_resolve(), if we don't like allocating unnecessary
memory, why are we ok with traversing the BTF with noops? Seems
a bit inconsistent to me.

> 
> [...]