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

From: Marco Elver

Date: Tue Jan 27 2026 - 20:46:25 EST


On Wed, 28 Jan 2026 at 00:31, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Wed, 28 Jan 2026 00:08:10 +0100 Marco Elver <elver@xxxxxxxxxx> 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@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?
>
> 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!