Re: [PATCH bpf] libbpf: BTF dedup should ignore modifiers in type equivalence checks

[Alan Maguire <alan.maguire@oracle.com>]

On 09/01/2026 10:33, bot+bpf-ci@kernel.org wrote:
>> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
>> index 84a4b0abc8be..8ef0354e66cc 100644
>> --- a/tools/lib/bpf/btf.c
>> +++ b/tools/lib/bpf/btf.c
> 
> [ ... ]
> 
>> @@ -4688,7 +4686,24 @@ static int btf_dedup_is_equiv(struct btf_dedup *d, __u32 cand_id,
>>  		return fwd_kind == real_kind;
>>  	}
>>
>> -	if (cand_kind != canon_kind)
>> +	/*
>> +	 * Types are considered equivalent if modifiers (const, volatile,
>> +	 * restrict) are present for one but not the other.
>> +	 */
>> +	if (cand_kind != canon_kind) {
>> +		__u32 next_cand_id = cand_id;
>> +		__u32 next_canon_id = canon_id;
>> +
>> +		if (btf_is_mod(cand_type) && !btf_is_type_tag(cand_type))
>> +			next_cand_id = cand_type->type;
>> +		if (btf_is_mod(canon_type) && !btf_is_type_tag(canon_type))
>> +			next_canon_id = canon_type->type;
>> +		if (cand_id == next_cand_id && canon_id == next_canon_id)
>> +			return 0;
>> +		return btf_dedup_is_equiv(d, next_cand_id, next_canon_id);
>> +	}
> 
> Can this recursive call fail when there are multiple levels of modifiers?
> 
> Consider comparing "volatile const int" (cand_id=20) against "int" (canon_id=5):
> 
> 1. The first call adds hypot_map[5] = 20 via btf_dedup_hypot_map_add()
>    earlier in btf_dedup_is_equiv() before the kinds are checked.
> 
> 2. btf_is_mod(VOLATILE) is true, so next_cand_id becomes the underlying
>    "const int" (ID=15), while next_canon_id stays at 5 since INT is not
>    a modifier.
> 
> 3. The recursive call btf_dedup_is_equiv(d, 15, 5) is made.
> 
> 4. In the recursive call, hypot_map[5] is already set to 20 (from step 1).
>    Since 20 != 15, the code falls through to btf_dedup_identical_types().
> 
> 5. btf_dedup_identical_types(d, 20, 15) compares VOLATILE vs CONST kinds,
>    which differ, so it returns false.
> 
> 6. The function returns 0, incorrectly reporting the types as not equivalent.
> 
> This appears to break the intended behavior for types with nested modifiers
> like "volatile const X" vs "X", even though single modifiers like
> "volatile X" vs "X" would work correctly (because next_cand_id and
> next_canon_id would both resolve to the same underlying type).
> 
> 

The above is all true, but I _think_ it neglects an aspect of deduplication;
that it is symmetric; i.e. in one case a type id is canonical, and in another
it is a candidate. So for the above case, consider what happens when
cand_id=5 ("int") and canon_id=20 ("volatile const int"):

1. we add hypot_map[20] = 5 (i.e hypot_map["volatile const int"] = "int";
2. btf_is_mod(VOLATILE) is true so we recurse to btf_dedup_is_equiv(d, 5, 15)
   (where 15 is "const int")
3. hypot_map[15] is not set so we do equivalence checking and recurse to
   btf_dedup_is_equiv(d, 5, 5) ("int") and return 1.
4. As a result the original hypot_map["volatile const int"] = "int" is
   verified.

So unless I'm missing something we end up deduplicating successfully in 
this case, but the deduplication is weighted towards making the more complex 
type canonical. That's what we want I think since these equivalence checks 
will be just used to validate struct/union equivalence.

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