Message-ID: <CAMj1kXGJhrwg06Z2X9ZZKQ2XmgQ7N0_D-TJy+iySRmYzOMnGkw@mail.gmail.com>
Date: Thu, 6 Feb 2025 10:31:31 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: WangYuli <wangyuli@...ontech.com>
Cc: gregkh@...uxfoundation.org, chenhuacai@...nel.org, chenhuacai@...ngson.cn, 
	kernel@...0n.name, linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, 
	loongarch@...ts.linux.dev, masahiroy@...nel.org, nathan@...nel.org, 
	ndesaulniers@...gle.com, nicolas@...sle.eu, sashal@...nel.org, 
	stable@...r.kernel.org
Subject: Re: Re: [PATCH 6.1&6.6 0/3] kbuild: Avoid weak external linkage where possible

On Thu, 6 Feb 2025 at 09:53, WangYuli <wangyuli@...ontech.com> wrote:
>
> Hi, Greg,
>
> It's rather unfortunate that currently, almost all Linux distributions
> supporting LoongArch are using LTS kernels version v6.6 or older, such as
> openEuler and deepin. [1][2]
>
> If this bugfix isn't merged into linux-stable, then every single distro
> kernel team will have to waste time fixing the same darn bug over and
> over, even though it's already fixed in later kernels.
>
> This would really make LTS look like it's failing to serve its intended
> purpose. And I'm sure all of us do not want to see something so terrible
> happen.
>
> On Fri, Dec 6, 2024 at 9:04 PM Greg Kroah-Hartman wrote:
> > Odd, why doesn't this affect other arches as well using new binutils?  I
> > hate to have to backport all of this just for one arch, as that feels
> > odd.
>
> Could you help me understand why you expressed that you "hate" to have
> to backport something for only one arch?
> Given that we've historically done quite a bit of similar backporting for
> architectures such as arm, powerpc, and x86...It's not exactly unprecedented.
> I just want to grasp the rationale, as it all seems perfectly justified
> and necessary.
>
> Moreover, with all the active and strict code reviews by all developers,
> such occurrences are not frequent on LoongArch. You could be not exactly
> "always" backporting something like this just for LoongArch, so perhaps
> that might make you and your colleagues feel a little less "hate" :-)
>
> As for your questions on the root cause of the issue and the effectiveness
> of this fix, I reckon Xi Ruoyao's explanation and Ard Biesheuvel's
> supplementary points have already provided ample details. [3][4][5]
>
> If, after your feedback, you still have any lingering doubts regarding the
> issue itself or the LoongArch architecture, I believe that Xi Ruoyao,
> Ard Biesheuvel, and Huacai Chen would all be more than willing to elaborate
> further.
>
> I'm bringing this up because we've encountered concrete issues in the
> process of maintaining distributions. Furthermore, as an upstream resource,
> linux-stable can help us more effectively drive forward community
> development efforts.
> Plus, we realize this benefits all Linux community developers just the same.
>
> Hoping you could spare a moment from your busy schedule to take another look
> at this patch series and perhaps reconsider the LTS inclusion of this bugfix.
>
> [1]. https://gitee.com/openeuler/kernel/blob/openEuler-25.03/Makefile#L3
> [2]. https://github.com/deepin-community/kernel/blob/linux-6.6.y/Makefile#L3
> [3]. https://lore.kernel.org/all/ccb1fa9034b177042db8fcbe7a95a2a5b466dc30.camel@xry111.site/
> [4]. https://lore.kernel.org/all/CAMj1kXEV+HC+2HMLhDaLfAufQLrXRs2J7akMNr1mjejDYc7kdw@mail.gmail.com/#t
> [5]. https://lore.kernel.org/all/c9a43e5da01ee2215393c0f3c50956171fe660ab.camel@xry111.site/
>

You might consider sending a Loongarch-only patch for mainline that
adds weak definitions of these symbols, and backport that to -stable
once it hits Linus's tree. That way, the weak references are always
satisfied, even during the first linker pass.

Powered by blists - more mailing lists