Re: [PATCH] kcsan, compiler_types: avoid duplicate type issues in BPF Type Format

[Marco Elver]

On Fri, 16 Jan 2026 at 11:13, Marco Elver <elver@xxxxxxxxxx> wrote:
> On Fri, 16 Jan 2026 at 10:17, Alan Maguire <alan.maguire@xxxxxxxxxx> 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@xxxxxxxxxxxxx>
> > Suggested-by: Marco Elver <elver@xxxxxxxxxx>
> > Signed-off-by: Alan Maguire <alan.maguire@xxxxxxxxxx>
>
> Reviewed-by: Marco Elver <elver@xxxxxxxxxx>

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