Re: [PATCH v4 00/30] tools build: Append -fzero-init-padding-bits=all option

[Andrew Morton]

On Wed, 11 Mar 2026 09:23:31 +0000 Leo Yan <leo.yan@xxxxxxx> wrote:

> On Wed, Mar 11, 2026 at 08:52:52AM +0000, Jonathan Cameron wrote:
> > On Wed, 11 Mar 2026 09:44:16 +0100
> > Daniel Lezcano <daniel.lezcano@xxxxxxxxxxxxxxxx> wrote:
> > 
> > > Hi Leo,
> > > 
> > > On 3/11/26 09:29, Leo Yan wrote:
> > > > Thank you for reviewing v3 and I appreciate much Ian's suggestions, most
> > > > of which have been adopted into this series.
> > > > 
> > > > For anyone new to the series, the reason for appending this compiler
> > > > option is described in v3 (see "Link to v3" below).
> > > > 
> > > > In this version, the changes are organized into three parts:
> > > > 
> > > >    Patches 01 – 07: Preparation before adding the new compiler option.
> > > >                     Fix typos, adjust Makefiles to ensure the newly
> > > >                     introduced option does not cause regressions.
> > > >    Patch 08:        Propagate -fzero-init-padding-bits=all to
> > > >                     EXTRA_CFLAGS and HOST_EXTRACFLAGS for the
> > > >                     CC and HOSTCC compilers, respectively.
> > > >    Patches 09 – 30: Apply EXTRA_CFLAGS and HOST_EXTRACFLAGS in
> > > >                     project Makefiles.
> > > >   
> > > Through which tree do you expect these patch to be picked up ? Each 
> > > maintainer picks the patches related to their subsystem ?

My common approach to this sort of thing (which works) is to put
everything into mm.git, try to cc the whole world.

If Mark alerts us to the appearance of particular patches in linux-next
via another tree, I drop the mm.git copy, so maintainers can simply
cherrypick things and it's all automatic.

If maintainers send an ack (easiest!) then great.

Whatever is left over I upstream in the next merge window.

> > If that's the case it would be helpful to +CC the relevant
> > subsystem lists on the patches that you expect to go that path.
> 
> I deliberately looped mainatiners but not CC'ed each subsystem lists,
> as it is a long list so I don't want to spam them.
> 
> If we conclude to go via subsystem trees, I will CC subsystem lists.
> Thanks for reminding.

Sure.

I can ensure that the appropriate maintainers are cc'ed on the relevant
mm.git commits.    I generally don't auto-cc mailing lists - I already spray
out too many emails!