Re: [PATCH RESEND v2] tools build: Use -fzero-init-padding-bits=all

[Nathan Chancellor]

On Wed, Feb 25, 2026 at 09:22:10AM +0000, Leo Yan wrote:
> On Tue, Feb 24, 2026 at 01:11:19PM -0800, Kees Cook wrote:
> > On Tue, Feb 24, 2026 at 10:19:56AM -0700, Nathan Chancellor wrote:
> > > Kbuild does not maintain/touch tools/. This should go via another tree
> > > like perf or something. It does not look like
> > > tools/scripts/Makefile.include has a clear owner, perf and bpf tend to
> > > be the ones who touch it the most.
> 
> This is a circular deadlock.  Namhyung (the perf maintainer) advised me
> to send patch to the linux-kbuild [1], for fixing an union init issue
> found recently.

The tools/ build system is not Kbuild, so I do not want to take patches
for it, sorry. Issues from patches I take become my responsibility to
deal with and I am not at all familiar with the tools build system
because I am not a consumer of it. Nicolas may feel differently but I am
going to assume not based on his level of expertise with tools/ [1]. I
am not trying to deadlock you though.

Namhyung, I think this patch can reasonably go via the perf tree since
it will be a primary consumer of it.

> > You could claim it! ;)

Heh, Kbuild and ClangBuiltLinux give me more than enough to do around
here ;)

> > Regardless, I like to see cc-option available here, as I doubt this will
> > be the last conditional option for tool builds. (Actually, are there
> > other conditional options that could use this today in the tools
> > Makefiles?)
> 
> Some subprojects in tools have their own conditional options.
> 
> This patch is ambitious that it changes the global Makefile.include file
> so it can propagate the '-fzero-init-padding-bits=all' option to
> projects that include it.  Why do we need to do this globally?  This is
> because Perf needs to build several subprojects (libperf and bpftool).

This seems like a great reason for it to go via the perf tree as noted
above.

[1]: https://lore.kernel.org/aNhGp7NDCCrtwJqm@levanger/

Cheers,
Nathan