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 <[email protected]> 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
