[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANpmjNNnMiUd4eb05fXCndJTd_WB9TRB_O0AB9+C4BCgrF3ZDw@mail.gmail.com>
Date: Wed, 28 Jan 2026 02:44:57 +0100
From: Marco Elver <elver@...gle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Alan Maguire <alan.maguire@...cle.com>, kees@...nel.org, nathan@...nel.org,
peterz@...radead.org, ojeda@...nel.org, ubizjak@...il.com, Jason@...c4.com,
Marc.Herbert@...ux.intel.com, hca@...ux.ibm.com, hpa@...or.com,
namjain@...ux.microsoft.com, paulmck@...nel.org, linux-kernel@...r.kernel.org,
andrii.nakryiko@...il.com, yonghong.song@...ux.dev, ast@...nel.org,
jolsa@...nel.org, daniel@...earbox.net, martin.lau@...ux.dev,
eddyz87@...il.com, song@...nel.org, john.fastabend@...il.com,
kpsingh@...nel.org, sdf@...ichev.me, haoluo@...gle.com, bvanassche@....org,
nilay@...ux.ibm.com, bpf@...r.kernel.org
Subject: Re: [PATCH] kcsan, compiler_types: avoid duplicate type issues in BPF
Type Format
On Wed, 28 Jan 2026 at 00:31, Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> On Wed, 28 Jan 2026 00:08:10 +0100 Marco Elver <elver@...gle.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@...ux.ibm.com>
> > > > Suggested-by: Marco Elver <elver@...gle.com>
> > > > Signed-off-by: Alan Maguire <alan.maguire@...cle.com>
> > >
> > > Reviewed-by: Marco Elver <elver@...gle.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!
Powered by blists - more mailing lists