[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wi4OHkFuwCGXOsPNZ9=UeewcbvOdB79PqGjRVVtT0z3NQ@mail.gmail.com>
Date: Wed, 3 Dec 2025 12:30:37 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Laight <david.laight.linux@...il.com>
Cc: Ingo Molnar <mingo@...nel.org>, Josh Poimboeuf <jpoimboe@...nel.org>, x86@...nel.org,
linux-kernel@...r.kernel.org, Nathan Chancellor <nathan@...nel.org>,
Peter Zijlstra <peterz@...radead.org>, Alexandre Chartre <alexandre.chartre@...cle.com>
Subject: Re: [PATCH] objtool: Fix stack overflow in validate_branch()
On Wed, 3 Dec 2025 at 11:37, David Laight <david.laight.linux@...il.com> wrote:
>
> Both allmodconfig and allyesconfig should probably manage to disable KASAN.
> Apart from building faster, the object files will be more realistic.
The problem is that it would cut down on build coverage a lot. We've
had lots of build things where KASAN makes things much worse, and
_finding_ them is worthwhile.
In fact, I'd argue that this objtool issue is very much one such
thing, where KASAN makes for horrid code generation and in the process
then finds scalability issues with objtool.
Is it a *realistic* build config? No. But that's not the point. The
point is literally to find weak points in our infrastructure by having
big configurations that do odd things.
Nobody sane should run an allmodconfig kernel in any kind of real life
situation - it's about getting reasonable build coverage.
That said, I'd love to have a faster allmodconfig build, and so I
would like to eventually get rid of KASAN as part of the build just
for that reason if we'd just feel that it's not adding enough value.
But I do think it has found enough coverage issues that we're not there yet.
Linus
Powered by blists - more mailing lists