linux-kernel - Re: BUG: arm64: missing build-id from vmlinux

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0ab93345-18e1-15c9-a4a3-066ea1cd862b@leemhuis.info>
Date:   Wed, 21 Dec 2022 17:29:44 +0100
From:   Thorsten Leemhuis <regressions@...mhuis.info>
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     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>,
        Ard Biesheuvel <ardb@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: BUG: arm64: missing build-id from vmlinux

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.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.