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: <560d73a8-2f2a-4844-44ff-afffad9c8694@loongson.cn>
Date:   Mon, 6 Feb 2023 18:28:28 +0800
From:   Jianmin Lv <lvjianmin@...ngson.cn>
To:     David Laight <David.Laight@...LAB.COM>,
        'Huacai Chen' <chenhuacai@...nel.org>
Cc:     Huacai Chen <chenhuacai@...ngson.cn>,
        Arnd Bergmann <arnd@...db.de>,
        "loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        Xuefeng Li <lixuefeng@...ngson.cn>,
        Guo Ren <guoren@...nel.org>, Xuerui Wang <kernel@...0n.name>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] LoongArch: Make -mstrict-align be configurable



On 2023/2/3 下午4:46, David Laight wrote:
> From: Huacai Chen
>> Sent: 03 February 2023 02:01
>>
>> Hi, David,
>>
>> On Thu, Feb 2, 2023 at 5:01 PM David Laight <David.Laight@...lab.com> wrote:
>>>
>>> From: Huacai Chen
>>>> Sent: 02 February 2023 08:43
>>>>
>>>> Introduce Kconfig option ARCH_STRICT_ALIGN to make -mstrict-align be
>>>> configurable.
>>>>
>>>> Not all LoongArch cores support h/w unaligned access, we can use the
>>>> -mstrict-align build parameter to prevent unaligned accesses.
>>>>
>>>> This option is disabled by default to optimise for performance, but you
>>>> can enabled it manually if you want to run kernel on systems without h/w
>>>> unaligned access support.
>>>
>>> Should there be an associated run-time check during kernel initialisation
>>> that a kernel compiled without -mstrict-align isn't being run on hardware
>>> that doesn't support unaligned accesses.
>>>
>>> It can be quite a while before you get a compiler-generated misaligned accesses.
>>
>> If we don't use -mstrict-align, the kernel cannot be run on hardware
>> that doesn't support unaligned accesses, so I think the run-time check
>> is useless, and it has no chance to run the checking.
> 
> If you don't add the check and someone boots the wrong type of kernel
> then they'll probably get a panic well after booting.
> You really do want a check in the bot code.
> 
Agree, maybe it's reasonable to check it at the beginning of cpu probe 
stuff.

> There is also the question of how userspace is compiled.
> You pretty much don't want to be taking traps to fixup misaligned accesses.
> So the default compiler options better include -mstrict-align.
> 
> You should look at -mno-strict-align being a performance option when
> running on known hardware, not a default.
> 
> 	David
> 
I think the key point of the patch is providing users with a high 
performance kernel for existed and future unaligned-access-supported 
Loongson CPUs (mainly for destop and server system, also called *big* 
CPU), which are dominant compared with unaligned-access-unsupported CPUs 
(mainly for customized embedded system, also called *small* CPU). By 
this way, we just want to provide *the vast majority of big CPU users* 
(desktop and server OS) with convenience to directly use high 
performance kernel without any extra compile option. Instead, for 
customized embedded system, we have to support them with an extra 
compile option. So, it seems that we have to reconcile default compile 
option between small CPU and big CPU, and sacrifice the convenience of 
small CPU.

For some specific diffirences with and without -mstrict-align, see:
https://lore.kernel.org/all/5303aeda-5c66-ede6-b3ac-7d8ebd73ec70@loongson.cn/

Thanks!
Jianmin


> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ