Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <8a79151b-ef75-08ad-ae3d-f6cdabfeaa47@gmail.com> <CAKbZUD3FBiaLGWq=TipfevqXP0SBz8F+=L6JSO+FMZOv0QQ9AQ@mail.gmail.com>
In-Reply-To: <CAKbZUD3FBiaLGWq=TipfevqXP0SBz8F+=L6JSO+FMZOv0QQ9AQ@mail.gmail.com>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Mon, 22 May 2023 08:33:47 +0200
Message-ID: <CAMj1kXEJj4+CFX3YfCZZu7RwxoVf=5PHZcZ8tG7x8xO3x4KPAw@mail.gmail.com>
Subject: Re: Regression. -6.3.X Good. -6.4-rcY Bad.
To:     Pedro Falcato <pedro.falcato@gmail.com>
Cc:     Bagas Sanjaya <bagasdotme@gmail.com>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Linux Kernel Build System <linux-kbuild@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Regressions <regressions@lists.linux.dev>,
        Linux EFI <linux-efi@vger.kernel.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Alan Bartlett <ajb@elrepo.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, 22 May 2023 at 03:15, Pedro Falcato <pedro.falcato@gmail.com> wrote=
:
>
> On Mon, May 22, 2023 at 1:43=E2=80=AFAM Bagas Sanjaya <bagasdotme@gmail.c=
om> wrote:
> >
> > Hi,
> >
> > I notice a simple build-time regression on Bugzilla [1]. Quoting from i=
t:
> >
> > > This is a very simple to see regression.
> > >
> > > On arm64 hardware, take any one of the -6.4-rcY tarballs created by L=
inus. Extract the contents of the tarball and cd to the linux-6.4-rcY direc=
tory. Issue a "make clean" or a "make mrproper" or a "make distclean" comma=
nd. Look at the output (there should not be any). In every case, the output=
 is --
> > >
> > > nm: 'vmlinux': No such file
> > >
...
> > > # first bad commit: [45dd403da851124412d32e3193c21de4a51d29da] efi/zb=
oot: arm64: Inject kernel code size symbol into the zboot payload
> > >
> > > Reverting the commit 45dd403da851124412d32e3193c21de4a51d29da resolve=
s the problem.
> >
> > The regression looks like arm-specific, but the first bad commit
> > IMO isn't related to kbuild system.
> >
> > Anyway, I'm adding it to regzbot:
> >
> > #regzbot introduced: 45dd403da85112 https://bugzilla.kernel.org/show_bu=
g.cgi?id=3D217468
> > #regzbot title: nm vmlinux ENOENT when "make mrproper" on arm64
>

How on earth is this a regression? It is not even a build error, only
a warning, with no adverse impact whatsoever on the resulting
binaries.

Could we stop being so trigger happy when calling things regressions, pleas=
e?

> I was able to track down the issue.
> In line 47, arch/arm64/boot/Makefile, a variable (that gets expanded
> on use, hence =3D and not :=3D) gets defined, that requires vmlinux to
> exist (see the $(shell) invocation).
> drivers/firmware/efi/libstub/Makefile.zboot then defines a variable
> with :=3D, which expands on site and not when it actually needs to be
> used. This expands EFI_ZBOOT_OBJCOPY_FLAGS without vmlinux existing,
> which ENOENTs.
>
> The below patch should fix it. I'm not submitting an actual patch
> because I simply don't know if there are any possible side effects
> here (although it frankly seems unlikely).
>
> diff --git a/drivers/firmware/efi/libstub/Makefile.zboot
> b/drivers/firmware/efi/libstub/Makefile.zboot
> index 89ef820f3b3..3fb39dea114 100644
> --- a/drivers/firmware/efi/libstub/Makefile.zboot
> +++ b/drivers/firmware/efi/libstub/Makefile.zboot
> @@ -32,7 +32,7 @@ zboot-size-len-$(CONFIG_KERNEL_GZIP)   :=3D 0
>  $(obj)/vmlinuz: $(obj)/vmlinux.bin FORCE
>         $(call if_changed,$(zboot-method-y))
>
> -OBJCOPYFLAGS_vmlinuz.o :=3D -I binary -O $(EFI_ZBOOT_BFD_TARGET)
> $(EFI_ZBOOT_OBJCOPY_FLAGS) \
> +OBJCOPYFLAGS_vmlinuz.o =3D -I binary -O $(EFI_ZBOOT_BFD_TARGET)
> $(EFI_ZBOOT_OBJCOPY_FLAGS) \
>                           --rename-section
> .data=3D.gzdata,load,alloc,readonly,contents
>  $(obj)/vmlinuz.o: $(obj)/vmlinuz FORCE
>         $(call if_changed,objcopy)
>

Thanks for the fix. So the reason I used =3D and not :=3D in the first
place in the assignment of EFI_ZBOOT_OBJCOPY_FLAGS was to ensure that
it will not be evaluated eagerly, but obviously, forcing the eager
evaluation further down defeats that.

I've sent this out as a patch and queued it up as a EFI fix. Thanks!