From: Leo Yan <leo.yan@arm.com>
To: Kees Cook <kees@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>,
Nicolas Schier <nsc@kernel.org>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Ian Rogers <irogers@google.com>,
Namhyung Kim <namhyung@kernel.org>,
James Clark <james.clark@linaro.org>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev
Subject: Re: [PATCH RESEND v2] tools build: Use -fzero-init-padding-bits=all
Date: Wed, 25 Feb 2026 09:22:10 +0000 [thread overview]
Message-ID: <20260225092210.GC4184494@e132581.arm.com> (raw)
In-Reply-To: <202602241310.C3641B97@keescook>
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:
> > Hi Leo,
> >
> > On Tue, Feb 24, 2026 at 12:16:40PM +0000, Leo Yan wrote:
> > > GCC-15 release claims [1]:
> > >
> > > {0} initializer in C or C++ for unions no longer guarantees clearing
> > > of the whole union (except for static storage duration initialization),
> > > it just initializes the first union member to zero. If initialization
> > > of the whole union including padding bits is desirable, use {} (valid
> > > in C23 or C++) or use -fzero-init-padding-bits=unions option to
> > > restore old GCC behavior.
> > >
> > > As a result, this new behaviour might cause unexpected data when we
> > > initialize a union with using the '{ 0 }' initializer.
> > >
> > > Since commit dce4aab8441d ("kbuild: Use -fzero-init-padding-bits=all"),
> > > the kernel has enabled -fzero-init-padding-bits=all to zero padding bits
> > > in unions and structures. This commit applies the same option for tools
> > > building.
> > >
> > > The option is not supported neither by any version older than GCC 15 and
> > > is also not supported by LLVM, this patch adds the cc-option function to
> > > dynamically detect the compiler option.
> > >
> > > [1] https://gcc.gnu.org/gcc-15/changes.html
> > >
> > > Signed-off-by: Leo Yan <leo.yan@arm.com>
> > > ---
> > > Resent to linux-kbuild mailing list.
> >
> > 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.
> You could claim it! ;)
>
> 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).
Thanks,
Leo
[1] https://lore.kernel.org/linux-perf-users/20260224122054.GB4184494@e132581.arm.com/T/#ma07fc114e84254d0173490409955e9d3bea147be
next prev parent reply other threads:[~2026-02-25 9:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-24 12:16 [PATCH RESEND v2] tools build: Use -fzero-init-padding-bits=all Leo Yan
2026-02-24 17:19 ` Nathan Chancellor
2026-02-24 21:11 ` Kees Cook
2026-02-25 9:22 ` Leo Yan [this message]
2026-02-25 19:25 ` Nathan Chancellor
2026-02-26 18:33 ` Namhyung Kim
2026-02-26 18:38 ` Namhyung Kim
2026-02-26 22:52 ` Quentin Monnet
2026-02-27 10:36 ` Leo Yan
2026-02-27 11:52 ` Quentin Monnet
2026-03-04 1:14 ` Namhyung Kim
2026-03-04 1:28 ` Quentin Monnet
2026-03-04 1:35 ` Namhyung Kim
2026-03-04 9:23 ` Leo Yan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260225092210.GC4184494@e132581.arm.com \
--to=leo.yan@arm.com \
--cc=acme@kernel.org \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=justinstitt@google.com \
--cc=kees@kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=namhyung@kernel.org \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=nsc@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.