Re: [PATCH 0/2] Noinstr fixes for K[CA]SAN with GCOV

Re: [PATCH 0/2] Noinstr fixes for K[CA]SAN with GCOV

[Marco Elver]

On Thu, 18 Dec 2025 at 10:51, Peter Zijlstra <peterz@infradead.org> wrote:
> On Sat, Dec 13, 2025 at 08:59:44AM +0900, Ard Biesheuvel wrote:
>
> > > After that I sat down and finally got around to implement the builtin
> > > that should solve this once and for all, regardless of where it's
> > > called: https://github.com/llvm/llvm-project/pull/172030
> > > What this will allow us to do is to remove the
> > > "K[AC]SAN_SANITIZE_noinstr.o := n" lines from the Makefile, and purely
> > > rely on the noinstr attribute, even in the presence of explicit
> > > instrumentation calls.
> > >
> >
> > Excellent! Thanks for the quick fix. Happy to test and/or look into
> > the kernel side of this once this lands.
>
> Well, would not GCC need to grow the same thing and then we must wait
> until these versions are the minimum supported versions for sanitizer
> builds.
>
> I mean, the extension is nice, but I'm afraid we can't really use it
> until much later :/

Unfortunately, yes. But let's try to get the builtin into Clang and
GCC now (for the latter, need to Cc GCC folks to help).

Then we wait for 5 years. :-)

There's a possibility to try and backport it to stable Clang and GCC
versions, but it's a long stretch (extremely unlikely).

Re: [PATCH 0/2] Noinstr fixes for K[CA]SAN with GCOV

[Segher Boessenkool]

Hi!

On Thu, Dec 18, 2025 at 10:56:48AM +0100, Marco Elver wrote:
> On Thu, 18 Dec 2025 at 10:51, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Sat, Dec 13, 2025 at 08:59:44AM +0900, Ard Biesheuvel wrote:
> >
> > > > After that I sat down and finally got around to implement the builtin
> > > > that should solve this once and for all, regardless of where it's
> > > > called: https://github.com/llvm/llvm-project/pull/172030
> > > > What this will allow us to do is to remove the
> > > > "K[AC]SAN_SANITIZE_noinstr.o := n" lines from the Makefile, and purely
> > > > rely on the noinstr attribute, even in the presence of explicit
> > > > instrumentation calls.
> > > >
> > >
> > > Excellent! Thanks for the quick fix. Happy to test and/or look into
> > > the kernel side of this once this lands.
> >
> > Well, would not GCC need to grow the same thing and then we must wait
> > until these versions are the minimum supported versions for sanitizer
> > builds.
> >
> > I mean, the extension is nice, but I'm afraid we can't really use it
> > until much later :/
> 
> Unfortunately, yes. But let's try to get the builtin into Clang and
> GCC now (for the latter, need to Cc GCC folks to help).
> 
> Then we wait for 5 years. :-)
> 
> There's a possibility to try and backport it to stable Clang and GCC
> versions, but it's a long stretch (extremely unlikely).

We (GCC) do not generally want to do backport features; even for
bugfixes the risk/reward ratio comes into the picture.  It *can* be done
if some feature is important enough of course.  If you have to wonder or
ask if your feature is important enough, it is not.

The reason we do not want backports of feature is it increases
maintenance cost a lot, and so, development costs as well.

I guess LLVM has a similar policy, but I of course do not speak for
them.

You might have more success getting the stuff backported to some
distro(s) you care about?  Or get people to use newer compilers more
quickly of course, "five years" before people have it is pretty
ridiculous, two years is at the tail end of things already.


Segher

Re: [PATCH 0/2] Noinstr fixes for K[CA]SAN with GCOV

[Peter Zijlstra]

On Thu, Dec 18, 2025 at 05:58:44AM -0600, Segher Boessenkool wrote:

> You might have more success getting the stuff backported to some
> distro(s) you care about?  Or get people to use newer compilers more
> quickly of course, "five years" before people have it is pretty
> ridiculous, two years is at the tail end of things already.

There is a difference between having and requiring it :/ Our current
minimum compiler version is gcc-8 or clang-15 (IIRC).

On the bright side, I think we can be more aggressively with compiler
versions for debug builds vs regular builds. Not being able to build a
KASAN/UBSAN/whateverSAN kernel isn't too big of a problem (IMO).

Re: [PATCH 0/2] Noinstr fixes for K[CA]SAN with GCOV

[Segher Boessenkool]

Hi!

On Thu, Dec 18, 2025 at 01:18:13PM +0100, Peter Zijlstra wrote:
> On Thu, Dec 18, 2025 at 05:58:44AM -0600, Segher Boessenkool wrote:
> 
> > You might have more success getting the stuff backported to some
> > distro(s) you care about?  Or get people to use newer compilers more
> > quickly of course, "five years" before people have it is pretty
> > ridiculous, two years is at the tail end of things already.
> 
> There is a difference between having and requiring it :/ Our current
> minimum compiler version is gcc-8 or clang-15 (IIRC).

Very much so.  If you have good reasons for requiring it, make sure you
voice that with your backport request!

Nothing we (again, GCC) do is *only* motivated by procedures.  We can do
unusual things in unusual situations.  But you need extraordinary
evidence for why extraordinary things would be needed, of course.  Does
that apply here, you think?

> On the bright side, I think we can be more aggressively with compiler
> versions for debug builds vs regular builds. Not being able to build a
> KASAN/UBSAN/whateverSAN kernel isn't too big of a problem (IMO).

Absolutely.  Just document the feature as needing a recent compiler!


Segher

Re: [PATCH 0/2] Noinstr fixes for K[CA]SAN with GCOV

[Marco Elver]

On Thu, 18 Dec 2025 at 13:54, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> Hi!
>
> On Thu, Dec 18, 2025 at 01:18:13PM +0100, Peter Zijlstra wrote:
> > On Thu, Dec 18, 2025 at 05:58:44AM -0600, Segher Boessenkool wrote:
> >
> > > You might have more success getting the stuff backported to some
> > > distro(s) you care about?  Or get people to use newer compilers more
> > > quickly of course, "five years" before people have it is pretty
> > > ridiculous, two years is at the tail end of things already.
> >
> > There is a difference between having and requiring it :/ Our current
> > minimum compiler version is gcc-8 or clang-15 (IIRC).
>
> Very much so.  If you have good reasons for requiring it, make sure you
> voice that with your backport request!
>
> Nothing we (again, GCC) do is *only* motivated by procedures.  We can do
> unusual things in unusual situations.  But you need extraordinary
> evidence for why extraordinary things would be needed, of course.  Does
> that apply here, you think?
>
> > On the bright side, I think we can be more aggressively with compiler
> > versions for debug builds vs regular builds. Not being able to build a
> > KASAN/UBSAN/whateverSAN kernel isn't too big of a problem (IMO).
>
> Absolutely.  Just document the feature as needing a recent compiler!

For future reference:
https://discourse.llvm.org/t/explicit-sanitizer-checks-with-builtin-allow-sanitize-check/89383
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123442

Clang 22 should have the builtin.