linux-kernel - Re: Re: [PATCH 6.1&6.6 0/3] kbuild: Avoid weak external linkage where possible

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <F6E14B0130692444+20250206083705.63378-1-wangyuli@uniontech.com>
Date: Thu,  6 Feb 2025 16:37:02 +0800
From: WangYuli <wangyuli@...ontech.com>
To: gregkh@...uxfoundation.org
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: Re: [PATCH 6.1&6.6 0/3] kbuild: Avoid weak external linkage where possible

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/

Best Regards,
--
WangYuli