Message-ID: <17f2c722-a32b-482b-9363-6a415443fb40@loongson.cn>
Date: Fri, 5 Sep 2025 14:49:44 +0800
From: Ming Wang <wangming01@...ngson.cn>
To: Greg KH <gregkh@...uxfoundation.org>, WangYuli <wangyuli@...ontech.com>
Cc: ardb@...nel.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: [PATCH 6.1&6.6 0/3] kbuild: Avoid weak external linkage where
 possible

Hi Greg, all,

On 2/6/25 18:03, Greg KH wrote:
> On Thu, Feb 06, 2025 at 04:37:02PM +0800, WangYuli 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.
> 
> LTS is here to ensure that the original release of these branches, keeps
> working for that branch.  Adding support for newer toolchains sometimes
> happens, but is not a requirement or a normal thing to do as that really
> isn't a "regression", right?
> 
> Most of the time, fixing things up for newer compilers is simple.
> Sometimes it is not simple.  The "not simple" ones we usually just do
> not backport as that causes extra work for everyone over time.
> 
> As for the distros like openEuler, and deepin, they are free to add
> these patches there, on top of their other non-LTS patches, right?
> 
> thanks,
> 
> greg k-h

I'm writing to follow up on this important discussion. I have carefully
read the entire thread, including your explanation of the LTS philosophy
regarding support for new toolchains. I understand and respect the
principle that LTS aims to maintain stability for the environment in
which it was released, and that adapting to future toolchains is
primarily a distributor's responsibility.

However, I would like to respectfully ask for a reconsideration by
framing this issue from a slightly different perspective, based on the
excellent technical analysis provided by Xi Ruoyao and Ard Biesheuvel.

This situation appears to be more than just an incompatibility with a
"newer" toolchain. As Xi Ruoyao detailed, the older toolchains did not
"work correctly" but instead had a silent bug that produced incorrect
code for undefined weak symbols on LoongArch. The new binutils version
did not introduce a regression, but rather, it correctly started
erroring out on this problematic code pattern, thus exposing a
pre-existing, latent issue.

 From this viewpoint, this patch series is less about "adding support for
a new toolchain" and more about "fixing a latent bug that was previously
hidden by silent toolchain defects."

Furthermore, the patches themselves, originally authored by Ard, 
represent a clean, correct, and low-risk improvement. They were accepted 
into the mainline not just as a workaround, but as a superior way to 
handle these symbols, improving codegen for all architectures. 
Backporting this series would therefore be applying a high-quality, 
vetted bug fix that also has the fortunate side effect of resolving this 
build failure.

While the build failure currently only manifests on LoongArch, the
underlying code improvement is generic. For a relatively new 
architecture like LoongArch, ensuring that the primary LTS kernels are 
usable with modern, widely-adopted toolchains is crucial for the health 
and growth of its ecosystem within the broader Linux community. As 
WangYuli pointed out, this would prevent fragmented efforts across 
multiple distributions.

In summary, we believe this case is exceptional because the patch fixes
a latent issue exposed by a toolchain correction and represents a clean,
mainline-accepted improvement. We would be very grateful if you could
take another look at this series from this perspective.

Thank you for your time.

Best Regards,
Robin

Powered by blists - more mailing lists