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

[Namhyung Kim]

Hello,

On Wed, Feb 25, 2026 at 12:25:05PM -0700, Nathan Chancellor wrote:
> 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.

Sorry for the trouble.  I'm fine to take it to the perf tree once
everyone involved is happy about it.  Let me CC the bpf list in the
original patch.

Thanks,
Namhyung

> 
> > > 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