Re: kernel build failure when CONFIG_DEBUG_INFO_BTF and CONFIG_KCSAN are enabled

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

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!