[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20260127153129.2ca728a4550375a4172e1351@linux-foundation.org>
Date: Tue, 27 Jan 2026 15:31:29 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Marco Elver <elver@...gle.com>
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 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.
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.
Powered by blists - more mailing lists