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