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:

quoted

On 28/11/2025 06:27, Nilay Shroff wrote:

quoted

Hi Alan,

On 11/27/25 9:06 PM, Alan Maguire wrote:

quoted

On 27/11/2025 11:19, Jiri Olsa wrote:

quoted

On Wed, Nov 26, 2025 at 03:59:28PM +0530, Nilay Shroff wrote:

quoted

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 <redacted>
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/ (local)

Reported-by: Nilay Shroff <redacted>
Signed-off-by: Alan Maguire <redacted>
---
 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<redacted>