Re: [PATCH v2 00/21] kbuild: significantly speed up kernel builds

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Tue, Sep 15, 2026 at 10:53:51AM +0200, Arnd Bergmann wrote:
> On Mon, Sep 14, 2026, at 17:53, Linus Torvalds wrote:
> > On Mon, 14 Sept 2026 at 08:41, Kees Cook <kees@kernel.org> wrote:
> >>
> >> One area I think might solved via an LLM is the 3-pass kallsyms stuff.
> >> If we could get a deterministic kallsyms build in 1 pass, that would be
> >> very nice. A lot of people have tried, but it has eluded upstreaming.
> >
> > Even the three-pass one hasn't apparently always been entirely
> > deterministic. We've had random reports over the years of it failing
> > in some circumstances.
>
> This tends to break whenever a linker (rather than the compiler) starts
> creating a new type of symbols that show up in pass 2.
>
> > Maybe we've fixed it all, or maybe the failures just go imperceptibly
> > rare. Regardless, it has definitely been fragile.
>
> The rate seems to be once every few years, looking at the list
> of exceptions added to scripts/kallsyms.c (now scripts/mksysmap):
>
> efe6e3068067 ("kallsyms: fix nonconverging kallsyms table with lld")
> 516d980f8541 ("scripts/kallsyms: skip ppc compiler stub *.long_branch.* / *.plt_branch.*")
> b9b74be163a2 ("ARM: 8555/1: kallsyms: ignore ARM mode switching veneers")
>
> I'm sure there are other instances on architectures that get less
> build coverage.

Yeah, it's stuff like this that makes it more sensible in general to use
existing tooling where that makes sense, e.g. also the .mod.S stuff.

Though I also think dropping some of these arches would be a good idea ;)
*ahem*.

In any case, I think the bigger picture ideas like a single pass kallsyms is
stuff for the future.

The way I see it: grab the really low-hanging fruit (this series), then the
medium-hanging fruit, and only then enter the pits of hell to fight the
satanic hordes which clasp on to what remains.

>
>      Arnd

--
Cheers, Lorenzo