Message-ID: <CAK7LNATQ-NjYxPvGf4o6N5mp9kS07fpphcEn4_9LOMtS2nTbmQ@mail.gmail.com>
Date:   Sun, 25 Dec 2022 11:16:19 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Thorsten Leemhuis <regressions@...mhuis.info>,
        Will Deacon <will@...nel.org>, linux-arch@...r.kernel.org,
        Nicolas Schier <nicolas@...sle.eu>,
        linux-kernel@...r.kernel.org, Dennis Gilmore <dennis@...il.us>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        Catalin Marinas <catalin.marinas@....com>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: BUG: arm64: missing build-id from vmlinux

On Thu, Dec 22, 2022 at 8:53 PM Ard Biesheuvel <ardb@...nel.org> wrote:
>
> On Wed, 21 Dec 2022 at 17:29, Thorsten Leemhuis
> <regressions@...mhuis.info> wrote:
> >
> > On 21.12.22 16:39, Masahiro Yamada wrote:
> > > On Wed, Dec 21, 2022 at 5:23 PM Thorsten Leemhuis
> > > <regressions@...mhuis.info> wrote:
> > >>
> > >> Hi, this is your Linux kernel regression tracker. CCing the regression
> > >> mailing list, as it should be in the loop for all regressions:
> > >> https://docs.kernel.org/admin-guide/reporting-regressions.html
> > >>
> > >> On 18.12.22 21:51, Dennis Gilmore wrote:
> > >>> The changes in https://lore.kernel.org/linux-arm-kernel/166783716442.32724.935158280857906499.b4-ty@kernel.org/T/
> > >>> result in vmlinux no longer having a build-id.
> > >>
> > >> FWIW, that's 994b7ac1697b ("arm64: remove special treatment for the link
> > >> order of head.o") from Masahiro merged through Will this cycle.
> > >>
> > >>> At the least, this
> > >>> causes rpm builds to fail. Reverting the patch does bring back a
> > >>> build-id, but there may be a different way to fix the regression
> > >>
> > >> Makes me wonder if other distros or CIs relying on the build-id are
> > >> broken, too.
> > >>
> > >> Anyway, the holiday season is upon us, hence I also wonder if it would
> > >> be best to revert above change quickly and leave further debugging for 2023.
> > >>
> > >> Masahiro, Will, what's your option on this?
> >
> > Masahiro, many thx for looking into this.
> >
> > > I do not understand why you rush into the revert so quickly.
> > > We are before -rc1.
> > > We have 7 weeks before the 6.2 release
> > > (assuming we will have up to -rc7).
> > >
> > > If we get -rc6 or -rc7 and we still do not
> > > solve the issue, we should consider reverting it.
> >
> > Because it looked like a regression that makes it harder for people and
> > CI systems to build and test mainline. To quote
> > Documentation/process/handling-regressions.rst (
> > https://docs.kernel.org/process/handling-regressions.html ):
> >
> > """
> >  * Fix regressions within two or three days, if they are critical for
> > some reason – for example, if the issue is likely to affect many users
> > of the kernel series in question on all or certain architectures. Note,
> > this includes mainline, as issues like compile errors otherwise might
> > prevent many testers or continuous integration systems from testing the
> > series.
> > """
> >
> > I suspect that other distros rely on the build-id as well. Maybe I'm
> > wrong with that, but even if only Fedora and derivatives are effected it
> > will annoy some people. Sure, each can apply the revert, but before that
> > everyone affected will spend time debugging the issue first. A quick
> > revert in mainline (with a reapply later together with a fix) thus IMHO
> > is the most efficient approach afaics.
> >
>
> Agree with Masahiro here.
>
> The issue seems to be caused by the fact that whichever object gets
> linked first gets to decide the type of a section, and so the .notes
> section will be of type NOTE if head.o gets linked first, or PROGBITS
> otherwise. The latter PROGBITS type seems to be the result of the
> compiler emitting .note.GNU-stack as PROGBITS rather than NOTE.
>
> The hunk below fixes it for me, by avoiding notes emitted as PROGBITS.
> I'll leave it to Masahiro to decide whether this should be fixed for
> arm64 only or for all architectures, but I suspect the latter would be
> most appropriate.
>
> Note that the kernel's rpm-pkg and binrpm-pkg targets seem to be
> unaffected by this.


Thanks for root-causing this.


I like to fix this for all architectures because riscv is also broken.

https://lore.kernel.org/lkml/20221224192751.810363-1-masahiroy@kernel.org/




> diff --git a/arch/arm64/include/asm/assembler.h
> b/arch/arm64/include/asm/assembler.h
> index 376a980f2bad08bb..10a172601fe7f53f 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -818,7 +818,7 @@ alternative_endif
>
>  #ifdef GNU_PROPERTY_AARCH64_FEATURE_1_DEFAULT
>  .macro emit_aarch64_feature_1_and, feat=GNU_PROPERTY_AARCH64_FEATURE_1_DEFAULT
> -       .pushsection .note.gnu.property, "a"
> +       .pushsection .note.gnu.property, "a", %note
>         .align  3
>         .long   2f - 1f
>         .long   6f - 3f


I did not fold this hunk in my patch.

I compiled with CONFIG_ARM64_BTI_KERNEL=y.

.note.gnu.property section in VDSO was already NOTE
without this hunk.







> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index 4c13dafc98b8400f..8a8044dea71b0609 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -160,6 +160,7 @@ SECTIONS
>         /DISCARD/ : {
>                 *(.interp .dynamic)
>                 *(.dynsym .dynstr .hash .gnu.hash)
> +               *(.note.GNU-stack) # emitted as PROGBITS
>         }
>
>         . = KIMAGE_VADDR;



-- 
Best Regards
Masahiro Yamada

Powered by blists - more mailing lists