Re: kernel build failure when CONFIG_DEBUG_INFO_BTF and CONFIG_KCSAN are enabled

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

On 08/01/2026 21:50, Yonghong Song wrote:
> 
> 
> On 11/27/25 7:36 AM, Alan Maguire wrote:
>> On 27/11/2025 11:19, Jiri Olsa wrote:
>>> On Wed, Nov 26, 2025 at 03:59:28PM +0530, Nilay Shroff wrote:
>>>> Hi,
>>>>
>>>> I am encountering the following build failures when compiling the kernel source checked out
>>>> from the for-6.19/block branch [1]:
>>>>
>>>>    KSYMS   .tmp_vmlinux2.kallsyms.S
>>>>    AS      .tmp_vmlinux2.kallsyms.o
>>>>    LD      vmlinux.unstripped
>>>>    BTFIDS  vmlinux.unstripped
>>>> WARN: multiple IDs found for 'task_struct': 110, 3046 - using 110
>>>> WARN: multiple IDs found for 'module': 170, 3055 - using 170
>>>> WARN: multiple IDs found for 'file': 697, 3130 - using 697
>>>> WARN: multiple IDs found for 'vm_area_struct': 714, 3140 - using 714
>>>> WARN: multiple IDs found for 'seq_file': 1060, 3167 - using 1060
>>>> WARN: multiple IDs found for 'cgroup': 2355, 3304 - using 2355
>>>> WARN: multiple IDs found for 'inode': 553, 3339 - using 553
>>>> WARN: multiple IDs found for 'path': 586, 3369 - using 586
>>>> WARN: multiple IDs found for 'bpf_prog': 2565, 3640 - using 2565
>>>> WARN: multiple IDs found for 'bpf_map': 2657, 3837 - using 2657
>>>> WARN: multiple IDs found for 'bpf_link': 2849, 3965 - using 2849
>>>> [...]
>>>> make[2]: *** [scripts/Makefile.vmlinux:72: vmlinux.unstripped] Error 255
>>>> make[2]: *** Deleting file 'vmlinux.unstripped'
>>>> make[1]: *** [/home/src/linux/Makefile:1242: vmlinux] Error 2
>>>> make: *** [Makefile:248: __sub-make] Error 2
>>>>
>>>>
>>>> The build failure appears after commit 42adb2d4ef24 (“fs: Add the __data_racy annotation
>>>> to backing_dev_info.ra_pages”) and commit 935a20d1bebf (“block: Remove queue freezing
>>>> from several sysfs store callbacks”). However, the root cause does not seem to be specific
>>> yep, looks like __data_racy macro that adds 'volatile' to struct member is causing
>>> the mismatch during deduplication
>>>
>>> when you enable KCSAN some objects may opt out from it (via KCSAN_SANITIZE := n or
>>> such) and they will be compiled without __SANITIZE_THREAD__ macro defined which means
>>> __data_racy will be empty .. and we will get 2 versions of 'struct backing_dev_info'
>>> which cascades up to the task_struct and others
>>>
>>> not sure what's the best solution in here.. could we ignore volatile for
>>> the field in the struct during deduplication?
>>>
>> Yeah, it seems like a slightly looser form of equivalence matching might be needed.
>> The following libbpf change ignores modifiers in type equivalence comparison and
>> resolves the issue for me. It might be too big a hammer though, what do folks think?
>>
>>  From 160fb6610d75d3cdc38a9729cc17875a302a7189 Mon Sep 17 00:00:00 2001
>> From: Alan Maguire <alan.maguire@oracle.com>
>> Date: Thu, 27 Nov 2025 15:22:04 +0000
>> Subject: [RFC bpf-next] libbpf: BTF dedup should ignore modifiers in type
>>   equivalence checks
>>
>> We see identical type problems in [1] as a result of an occasionally
>> applied volatile modifier to kernel data structures. Such things can
>> result from different header include patterns, explicit Makefile
>> rules etc.  As a result consider types with modifiers (const, volatile,
>> restrict, type tag) as equivalent for dedup equivalence testing purposes.
>>
>> [1] https://lore.kernel.org/bpf/42a1b4b0-83d0-4dda-b1df-15a1b7c7638d@linux.ibm.com/
>>
>> Reported-by: Nilay Shroff <nilay@linux.ibm.com>
>> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
>> ---
>>   tools/lib/bpf/btf.c | 27 +++++++++++++++++++++------
>>   1 file changed, 21 insertions(+), 6 deletions(-)
>>
>> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
>> index e5003885bda8..384194a6cdae 100644
>> --- a/tools/lib/bpf/btf.c
>> +++ b/tools/lib/bpf/btf.c
>> @@ -4678,12 +4678,10 @@ static int btf_dedup_is_equiv(struct btf_dedup *d, __u32 cand_id,
>>       cand_kind = btf_kind(cand_type);
>>       canon_kind = btf_kind(canon_type);
>>   -    if (cand_type->name_off != canon_type->name_off)
>> -        return 0;
>> -
>>       /* FWD <--> STRUCT/UNION equivalence check, if enabled */
>> -    if ((cand_kind == BTF_KIND_FWD || canon_kind == BTF_KIND_FWD)
>> -        && cand_kind != canon_kind) {
>> +    if ((cand_kind == BTF_KIND_FWD || canon_kind == BTF_KIND_FWD) &&
>> +        cand_type->name_off == canon_type->name_off &&
>> +        cand_kind != canon_kind) {
>>           __u16 real_kind;
>>           __u16 fwd_kind;
>>   @@ -4700,7 +4698,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, type tag) 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))
>> +            next_cand_id = cand_type->type;
>> +        if (btf_is_mod(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);
>> +    }
>> +
>> +    if (cand_type->name_off != canon_type->name_off)
>>           return 0;
>>         switch (cand_kind) {
> 
> Thanks Alan. I can confirm that this fixed clang build issue as well.
> 
> As I mentioned earlier, the clang based kernel build will hang with both
> CONFIG_DEBUG_INFO_BTF and CONFIG_KCSAN enabled. I did a little bit
> debugging and found the repeated logs for the following code (btf.c)
> during dedup.
> 
>                                 if (cand_type->name_off) {
>                                         pr_debug("%s '%s' size=%d vlen=%d cand_id[%u] canon_id[%u] shallow-equal but not equiv for field#%d '%s': %d\n",
>                                                  cand_kind == BTF_KIND_STRUCT ? "STRUCT" : "UNION",
>                                                  btf__name_by_offset(d->btf, cand_type->name_off),
>                                                  cand_type->size, vlen, cand_id, canon_id, i,
>                                                  btf__name_by_offset(d->btf, cand_m->name_off), eq);
>                                 }
> 
> The following are some of logs:
> 
> ...
> libbpf: STRUCT 'static_call_key' size=16 vlen=2 cand_id[2719764] canon_id[1005933] shallow-equal but not equiv for field#1 '': 0
> libbpf: STRUCT 'tracepoint' size=72 vlen=8 cand_id[2719744] canon_id[1005913] shallow-equal but not equiv for field#2 'static_call_key': 0
> libbpf: STRUCT 'bpf_raw_event_map' size=32 vlen=4 cand_id[2722229] canon_id[1008430] shallow-equal but not equiv for field#0 'tp': 0
> ...
> libbpf: STRUCT 'static_call_key' size=16 vlen=2 cand_id[2719764] canon_id[1005933] shallow-equal but not equiv for field#1 '': 0
> libbpf: STRUCT 'tracepoint' size=72 vlen=8 cand_id[2719744] canon_id[1005913] shallow-equal but not equiv for field#2 'static_call_key': 0
> libbpf: STRUCT 'bpf_raw_event_map' size=32 vlen=4 cand_id[2722229] canon_id[1008430] shallow-equal but not equiv for field#0 'tp': 0
> ...
> libbpf: STRUCT 'static_call_key' size=16 vlen=2 cand_id[2719764] canon_id[1005933] shallow-equal but not equiv for field#1 '': 0
> libbpf: STRUCT 'tracepoint' size=72 vlen=8 cand_id[2719744] canon_id[1005913] shallow-equal but not equiv for field#2 'static_call_key': 0
> libbpf: STRUCT 'bpf_raw_event_map' size=32 vlen=4 cand_id[2722229] canon_id[1008430] shallow-equal but not equiv for field#0 'tp': 0
> ...
> 
> and looks they caused the infinite recursion.
> 
> Anyway, you above patch fixed the problem. Thanks!
> 

Thanks for the additional info; I'll try and repro the issue for clang. In terms
of the fix, the part I'm worried about is type tags; specifically if we end up
choosing the type without the type tag as the canonical type that ends up in
the deduplicated BTF we'd potentially end up losing critical info in the final
BTF representation. So I might tweak it slightly to eliminate type tag skipping; 
that shouldn't effect the resolution of this specific issue as far as I can see,
and it would be a bit less risky I think. 

I'll retest and send it out tomorrow all going well. Thanks!

Alan