Re: kernel build failure when CONFIG_DEBUG_INFO_BTF and CONFIG_KCSAN are enabled

[Nilay Shroff <nilay@linux.ibm.com>]

Hi Alan,

Gentle ping on this patch...

Did you get a chance to formally send this path upstream?
On the latest upstream kernel, I could still reproduce this 
error.

Thanks,
--Nilay

On 11/28/25 3:14 PM, Nilay Shroff wrote:
> 
> 
> On 11/28/25 1:23 PM, Alan Maguire wrote:
>> On 28/11/2025 06:27, Nilay Shroff wrote:
>>>
>>> Hi Alan,
>>>
>>> On 11/27/25 9:06 PM, 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 for your patch! I just applied it on my tree and rebuild the 
>>> tree. However I am still seeing the same compilation warnings. I am
>>> using the latest for-6.19/block branch[1].
>>>
>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git/log/?h=for-6.19/block 
>>>
>>
>> hi Nilay,
>>
>> The tricky part with testing this is ensure that pahole is using the updated libbpf 
>> rather than just the kernel itself. Did you  "make install" the modified libbpf and 
>> ensure that pahole was using it by building pahole with the cmake option 
>> -DLIBBPF_EMBEDDED=OFF ? That's the easiest way to ensure the change makes it into pahole; 
>> you can check shared library usage using  "ldd /usr/local/bin/pahole". The other option 
>> is to apply the change to the embedded libbpf in the lib/bpf directory in pahole.
>>
>> I tested the for-6.19/block branch with your config before and after making the
>> above change and applying it to pahole and things woorked. If that's doable from your
>> side that would be great. Thanks!
>>
> Thanks Alan! And obviously I didn't updated pahole using patched libbpf. Now I have 
> just updated pahole which uses the your patched libbpf. With this change, I confirmed
> that your patch fixes this compilation warnings for me. 
> 
> # which pahole
> /usr/local/bin/pahole
> 
> # ldd /usr/local/bin/pahole | grep libbpf
> 	libbpf.so.1 => /usr/local/lib64/libbpf.so.1 (0x00007fffa2fc0000)
> 
> With this test, please feel free to add,
> 
> Acked-by: Nilay Shroff<nilay@linux.ibm.com>
>