Enabling KCSAN is causing a large number of duplicate types
in BTF for core kernel structs like task_struct [1].
This is due to the definition in include/linux/compiler_types.h

`#ifdef __SANITIZE_THREAD__
...
`#define __data_racy volatile
..
`#else
...
`#define __data_racy
...
`#endif

Because some objects in the kernel are compiled without
KCSAN flags (KCSAN_SANITIZE) we sometimes get the empty
__data_racy annotation for objects; as a result we get multiple
conflicting representations of the associated structs in DWARF,
and these lead to multiple instances of core kernel types in
BTF since they cannot be deduplicated due to the additional
modifier in some instances.

Moving the __data_racy definition under CONFIG_KCSAN
avoids this problem, since the volatile modifier will
be present for both KCSAN and KCSAN_SANITIZE objects
in a CONFIG_KCSAN=y kernel.

Fixes: 31f605a308e6 ("kcsan, compiler_types: Introduce __data_racy type qualifier")
Reported-by: Nilay Shroff <nilay@linux.ibm.com>
Suggested-by: Marco Elver <elver@google.com>
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
---
 include/linux/compiler_types.h | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index d3318a3c2577..86111a189a87 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -303,6 +303,22 @@ struct ftrace_likely_data {
 # define __no_kasan_or_inline __always_inline
 #endif
 
+#ifdef CONFIG_KCSAN
+/*
+ * Type qualifier to mark variables where all data-racy accesses should be
+ * ignored by KCSAN. Note, the implementation simply marks these variables as
+ * volatile, since KCSAN will treat such accesses as "marked".
+ *
+ * Defined here because defining __data_racy as volatile for KCSAN objects only
+ * causes problems in BPF Type Format (BTF) generation since struct members
+ * of core kernel data structs will be volatile in some objects and not in
+ * others.  Instead define it globally for KCSAN kernels.
+ */
+# define __data_racy volatile
+#else
+# define __data_racy
+#endif
+
 #ifdef __SANITIZE_THREAD__
 /*
  * Clang still emits instrumentation for __tsan_func_{entry,exit}() and builtin
@@ -314,16 +330,9 @@ struct ftrace_likely_data {
  * disable all instrumentation. See Kconfig.kcsan where this is mandatory.
  */
 # define __no_kcsan __no_sanitize_thread __disable_sanitizer_instrumentation
-/*
- * Type qualifier to mark variables where all data-racy accesses should be
- * ignored by KCSAN. Note, the implementation simply marks these variables as
- * volatile, since KCSAN will treat such accesses as "marked".
- */
-# define __data_racy volatile
 # define __no_sanitize_or_inline __no_kcsan notrace __maybe_unused
 #else
 # define __no_kcsan
-# define __data_racy
 #endif
 
 #ifdef __SANITIZE_MEMORY__
-- 
2.39.3

On 1/16/26 1:17 AM, Alan Maguire wrote:
> Enabling KCSAN is causing a large number of duplicate types
> in BTF for core kernel structs like task_struct [1].
> This is due to the definition in include/linux/compiler_types.h
>
> `#ifdef __SANITIZE_THREAD__
> ...
> `#define __data_racy volatile
> ..
> `#else
> ...
> `#define __data_racy
> ...
> `#endif
>
> Because some objects in the kernel are compiled without
> KCSAN flags (KCSAN_SANITIZE) we sometimes get the empty
> __data_racy annotation for objects; as a result we get multiple
> conflicting representations of the associated structs in DWARF,
> and these lead to multiple instances of core kernel types in
> BTF since they cannot be deduplicated due to the additional
> modifier in some instances.
>
> Moving the __data_racy definition under CONFIG_KCSAN
> avoids this problem, since the volatile modifier will
> be present for both KCSAN and KCSAN_SANITIZE objects
> in a CONFIG_KCSAN=y kernel.
>
> Fixes: 31f605a308e6 ("kcsan, compiler_types: Introduce __data_racy type qualifier")
> Reported-by: Nilay Shroff <nilay@linux.ibm.com>
> Suggested-by: Marco Elver <elver@google.com>
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>

Tested on gcc15 and llvm22 and all works okay. Also
the patch itself makes sense, so

Acked-by: Yonghong Song <yonghong.song@linux.dev>

On 1/16/26 2:47 PM, Alan Maguire wrote:
> Enabling KCSAN is causing a large number of duplicate types
> in BTF for core kernel structs like task_struct [1].
> This is due to the definition in include/linux/compiler_types.h
> 
> `#ifdef __SANITIZE_THREAD__
> ...
> `#define __data_racy volatile
> ..
> `#else
> ...
> `#define __data_racy
> ...
> `#endif
> 
> Because some objects in the kernel are compiled without
> KCSAN flags (KCSAN_SANITIZE) we sometimes get the empty
> __data_racy annotation for objects; as a result we get multiple
> conflicting representations of the associated structs in DWARF,
> and these lead to multiple instances of core kernel types in
> BTF since they cannot be deduplicated due to the additional
> modifier in some instances.
> 
> Moving the __data_racy definition under CONFIG_KCSAN
> avoids this problem, since the volatile modifier will
> be present for both KCSAN and KCSAN_SANITIZE objects
> in a CONFIG_KCSAN=y kernel.
> 
> Fixes: 31f605a308e6 ("kcsan, compiler_types: Introduce __data_racy type qualifier")
> Reported-by: Nilay Shroff <nilay@linux.ibm.com>
> Suggested-by: Marco Elver <elver@google.com>
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> ---
>  include/linux/compiler_types.h | 23 ++++++++++++++++-------
>  1 file changed, 16 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
> index d3318a3c2577..86111a189a87 100644
> --- a/include/linux/compiler_types.h
> +++ b/include/linux/compiler_types.h
> @@ -303,6 +303,22 @@ struct ftrace_likely_data {
>  # define __no_kasan_or_inline __always_inline
>  #endif
>  
> +#ifdef CONFIG_KCSAN
> +/*
> + * Type qualifier to mark variables where all data-racy accesses should be
> + * ignored by KCSAN. Note, the implementation simply marks these variables as
> + * volatile, since KCSAN will treat such accesses as "marked".
> + *
> + * Defined here because defining __data_racy as volatile for KCSAN objects only
> + * causes problems in BPF Type Format (BTF) generation since struct members
> + * of core kernel data structs will be volatile in some objects and not in
> + * others.  Instead define it globally for KCSAN kernels.
> + */
> +# define __data_racy volatile
> +#else
> +# define __data_racy
> +#endif
> +
>  #ifdef __SANITIZE_THREAD__
>  /*
>   * Clang still emits instrumentation for __tsan_func_{entry,exit}() and builtin
> @@ -314,16 +330,9 @@ struct ftrace_likely_data {
>   * disable all instrumentation. See Kconfig.kcsan where this is mandatory.
>   */
>  # define __no_kcsan __no_sanitize_thread __disable_sanitizer_instrumentation
> -/*
> - * Type qualifier to mark variables where all data-racy accesses should be
> - * ignored by KCSAN. Note, the implementation simply marks these variables as
> - * volatile, since KCSAN will treat such accesses as "marked".
> - */
> -# define __data_racy volatile
>  # define __no_sanitize_or_inline __no_kcsan notrace __maybe_unused
>  #else
>  # define __no_kcsan
> -# define __data_racy
>  #endif
>  
>  #ifdef __SANITIZE_MEMORY__

Thanks Alan for working on this! I tested this change on my system and it works well.
So with that,

Tested-by: Nilay Shroff <nilay@linux.ibm.com>

On Fri, 16 Jan 2026 at 10:17, Alan Maguire <alan.maguire@oracle.com> wrote:
>
> Enabling KCSAN is causing a large number of duplicate types
> in BTF for core kernel structs like task_struct [1].
> This is due to the definition in include/linux/compiler_types.h
>
> `#ifdef __SANITIZE_THREAD__
> ...
> `#define __data_racy volatile
> ..
> `#else
> ...
> `#define __data_racy
> ...
> `#endif
>
> Because some objects in the kernel are compiled without
> KCSAN flags (KCSAN_SANITIZE) we sometimes get the empty
> __data_racy annotation for objects; as a result we get multiple
> conflicting representations of the associated structs in DWARF,
> and these lead to multiple instances of core kernel types in
> BTF since they cannot be deduplicated due to the additional
> modifier in some instances.
>
> Moving the __data_racy definition under CONFIG_KCSAN
> avoids this problem, since the volatile modifier will
> be present for both KCSAN and KCSAN_SANITIZE objects
> in a CONFIG_KCSAN=y kernel.

"KCSAN and KCSAN_SANITIZE objects" doesn't make sense.
"KCSAN_SANITIZE.. := n" objects?
Or just "instrumented and uninstrumented source files".
Anyway, I know what you mean, but others might not. :-)

> Fixes: 31f605a308e6 ("kcsan, compiler_types: Introduce __data_racy type qualifier")
> Reported-by: Nilay Shroff <nilay@linux.ibm.com>
> Suggested-by: Marco Elver <elver@google.com>
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>

Reviewed-by: Marco Elver <elver@google.com>

> ---
>  include/linux/compiler_types.h | 23 ++++++++++++++++-------
>  1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
> index d3318a3c2577..86111a189a87 100644
> --- a/include/linux/compiler_types.h
> +++ b/include/linux/compiler_types.h
> @@ -303,6 +303,22 @@ struct ftrace_likely_data {
>  # define __no_kasan_or_inline __always_inline
>  #endif
>
> +#ifdef CONFIG_KCSAN
> +/*
> + * Type qualifier to mark variables where all data-racy accesses should be
> + * ignored by KCSAN. Note, the implementation simply marks these variables as
> + * volatile, since KCSAN will treat such accesses as "marked".
> + *
> + * Defined here because defining __data_racy as volatile for KCSAN objects only
> + * causes problems in BPF Type Format (BTF) generation since struct members
> + * of core kernel data structs will be volatile in some objects and not in
> + * others.  Instead define it globally for KCSAN kernels.
> + */
> +# define __data_racy volatile
> +#else
> +# define __data_racy
> +#endif
> +
>  #ifdef __SANITIZE_THREAD__
>  /*
>   * Clang still emits instrumentation for __tsan_func_{entry,exit}() and builtin
> @@ -314,16 +330,9 @@ struct ftrace_likely_data {
>   * disable all instrumentation. See Kconfig.kcsan where this is mandatory.
>   */
>  # define __no_kcsan __no_sanitize_thread __disable_sanitizer_instrumentation
> -/*
> - * Type qualifier to mark variables where all data-racy accesses should be
> - * ignored by KCSAN. Note, the implementation simply marks these variables as
> - * volatile, since KCSAN will treat such accesses as "marked".
> - */
> -# define __data_racy volatile
>  # define __no_sanitize_or_inline __no_kcsan notrace __maybe_unused
>  #else
>  # define __no_kcsan
> -# define __data_racy
>  #endif
>
>  #ifdef __SANITIZE_MEMORY__
> --
> 2.39.3
>

On Fri, 16 Jan 2026 at 11:13, Marco Elver <elver@google.com> wrote:
> On Fri, 16 Jan 2026 at 10:17, Alan Maguire <alan.maguire@oracle.com> wrote:
> >
> > Enabling KCSAN is causing a large number of duplicate types
> > in BTF for core kernel structs like task_struct [1].
> > This is due to the definition in include/linux/compiler_types.h
> >
> > `#ifdef __SANITIZE_THREAD__
> > ...
> > `#define __data_racy volatile
> > ..
> > `#else
> > ...
> > `#define __data_racy
> > ...
> > `#endif
> >
> > Because some objects in the kernel are compiled without
> > KCSAN flags (KCSAN_SANITIZE) we sometimes get the empty
> > __data_racy annotation for objects; as a result we get multiple
> > conflicting representations of the associated structs in DWARF,
> > and these lead to multiple instances of core kernel types in
> > BTF since they cannot be deduplicated due to the additional
> > modifier in some instances.
> >
> > Moving the __data_racy definition under CONFIG_KCSAN
> > avoids this problem, since the volatile modifier will
> > be present for both KCSAN and KCSAN_SANITIZE objects
> > in a CONFIG_KCSAN=y kernel.
>
> "KCSAN and KCSAN_SANITIZE objects" doesn't make sense.
> "KCSAN_SANITIZE.. := n" objects?
> Or just "instrumented and uninstrumented source files".
> Anyway, I know what you mean, but others might not. :-)
>
> > Fixes: 31f605a308e6 ("kcsan, compiler_types: Introduce __data_racy type qualifier")
> > Reported-by: Nilay Shroff <nilay@linux.ibm.com>
> > Suggested-by: Marco Elver <elver@google.com>
> > Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
>
> Reviewed-by: Marco Elver <elver@google.com>

Which tree do compiler_types.h changes go through these days?

On Wed, 28 Jan 2026 00:08:10 +0100 Marco Elver <elver@google.com> wrote:

> > "KCSAN and KCSAN_SANITIZE objects" doesn't make sense.
> > "KCSAN_SANITIZE.. := n" objects?
> > Or just "instrumented and uninstrumented source files".
> > Anyway, I know what you mean, but others might not. :-)
> >
> > > Fixes: 31f605a308e6 ("kcsan, compiler_types: Introduce __data_racy type qualifier")
> > > Reported-by: Nilay Shroff <nilay@linux.ibm.com>
> > > Suggested-by: Marco Elver <elver@google.com>
> > > Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> >
> > Reviewed-by: Marco Elver <elver@google.com>
> 
> Which tree do compiler_types.h changes go through these days?

Thanks for poking.

compiler_types.h appears to be a free-for-all.  It's best to view such
a thing as a KCSAN patch rather than a compiler_types.h patch - that
the patch affects compiler_types.h is incidental.

31f605a308e6 came in via paulmck so convention (which perhaps only I
maintain) says "Paul", but whatever - getting the fix merged is the
important part.

So I'll grab Alan's patch, shall drop if it pops up in -next via a
different route.   Aiming for upstreaming in the next merge window.

It's unclear whether a -stable backport is required.  Thoughts on this
are sought.

On Wed, 28 Jan 2026 at 00:31, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 28 Jan 2026 00:08:10 +0100 Marco Elver <elver@google.com> wrote:
>
> > > "KCSAN and KCSAN_SANITIZE objects" doesn't make sense.
> > > "KCSAN_SANITIZE.. := n" objects?
> > > Or just "instrumented and uninstrumented source files".
> > > Anyway, I know what you mean, but others might not. :-)
> > >
> > > > Fixes: 31f605a308e6 ("kcsan, compiler_types: Introduce __data_racy type qualifier")
> > > > Reported-by: Nilay Shroff <nilay@linux.ibm.com>
> > > > Suggested-by: Marco Elver <elver@google.com>
> > > > Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> > >
> > > Reviewed-by: Marco Elver <elver@google.com>
> >
> > Which tree do compiler_types.h changes go through these days?
>
> Thanks for poking.
>
> compiler_types.h appears to be a free-for-all.  It's best to view such
> a thing as a KCSAN patch rather than a compiler_types.h patch - that
> the patch affects compiler_types.h is incidental.

I wasn't quite sure, given the conflict potential for this file - but
next time I'd take it through the kcsan tree then. This time around,
please continue to carry it.

> 31f605a308e6 came in via paulmck so convention (which perhaps only I
> maintain) says "Paul", but whatever - getting the fix merged is the
> important part.
>
> So I'll grab Alan's patch, shall drop if it pops up in -next via a
> different route.   Aiming for upstreaming in the next merge window.

Thanks!

> It's unclear whether a -stable backport is required.  Thoughts on this
> are sought.

I think it'd be appropriate!

On Tue, Jan 27, 2026 at 3:31 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 28 Jan 2026 00:08:10 +0100 Marco Elver <elver@google.com> wrote:
>
> > > "KCSAN and KCSAN_SANITIZE objects" doesn't make sense.
> > > "KCSAN_SANITIZE.. := n" objects?
> > > Or just "instrumented and uninstrumented source files".
> > > Anyway, I know what you mean, but others might not. :-)
> > >
> > > > Fixes: 31f605a308e6 ("kcsan, compiler_types: Introduce __data_racy type qualifier")
> > > > Reported-by: Nilay Shroff <nilay@linux.ibm.com>
> > > > Suggested-by: Marco Elver <elver@google.com>
> > > > Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> > >
> > > Reviewed-by: Marco Elver <elver@google.com>
> >
> > Which tree do compiler_types.h changes go through these days?
>
> Thanks for poking.
>
> compiler_types.h appears to be a free-for-all.  It's best to view such
> a thing as a KCSAN patch rather than a compiler_types.h patch - that
> the patch affects compiler_types.h is incidental.
>
> 31f605a308e6 came in via paulmck so convention (which perhaps only I
> maintain) says "Paul", but whatever - getting the fix merged is the
> important part.
>
> So I'll grab Alan's patch, shall drop if it pops up in -next via a
> different route.   Aiming for upstreaming in the next merge window.

You mean in the upcoming merge window, right?

The severity of the bug is significant. Better to land it sooner
rather than later.

> It's unclear whether a -stable backport is required.  Thoughts on this
> are sought.

Yes, since without it kcsan and bpf are mutually exclusive.

On Tue, 27 Jan 2026 16:02:32 -0800 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:

> > compiler_types.h appears to be a free-for-all.  It's best to view such
> > a thing as a KCSAN patch rather than a compiler_types.h patch - that
> > the patch affects compiler_types.h is incidental.
> >
> > 31f605a308e6 came in via paulmck so convention (which perhaps only I
> > maintain) says "Paul", but whatever - getting the fix merged is the
> > important part.
> >
> > So I'll grab Alan's patch, shall drop if it pops up in -next via a
> > different route.   Aiming for upstreaming in the next merge window.
> 
> You mean in the upcoming merge window, right?

Yes.

It could be added to 6.19-rcX/-stable if there's a need?

> The severity of the bug is significant. Better to land it sooner
> rather than later.

OK, that wasn't clear to me from the changelog.

> > It's unclear whether a -stable backport is required.  Thoughts on this
> > are sought.
> 
> Yes, since without it kcsan and bpf are mutually exclusive.

OK, cc:stable added.