linux-kernel - Re: [PATCH] LoongArch: Provide kernel fpu functions

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]

Date:   Mon, 6 Mar 2023 10:18:34 +0800
From:   WANG Xuerui <kernel@...0n.name>
To:     Huacai Chen <chenhuacai@...nel.org>, Xi Ruoyao <xry111@...111.site>
Cc:     Huacai Chen <chenhuacai@...ngson.cn>,
        Arnd Bergmann <arnd@...db.de>, loongarch@...ts.linux.dev,
        linux-arch@...r.kernel.org, Xuefeng Li <lixuefeng@...ngson.cn>,
        Guo Ren <guoren@...nel.org>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        linux-kernel@...r.kernel.org, loongson-kernel@...ts.loongnix.cn
Subject: Re: [PATCH] LoongArch: Provide kernel fpu functions

On 2023/3/6 09:55, Huacai Chen wrote:
> On Sun, Mar 5, 2023 at 9:28 PM Xi Ruoyao <xry111@...111.site> wrote:
>>
>> On Sun, 2023-03-05 at 20:18 +0800, Huacai Chen wrote:
>>>> Might be good to provide some explanation in the commit message as to
>>>> why the pair of helpers should be GPL-only. Do they touch state buried
>>>> deep enough to make any downstream user a "derivative work"? Or are the
>>>> annotation inspired by arch/x86?
>>> Yes, just inspired by arch/x86, and I don't think these symbols should
>>> be used by non-GPL modules.
>>
>> Hmm, what if one of your partners wish to provide a proprietary GPU
>> driver using the FPU like this way?  As a FLOSS developer I'd say "don't
>> do that, make your driver GPL".  But for Loongson there may be a
>> commercial issue.
> So use EXPORT_SYMBOL can make life easier?

As I've detailed in my first reply, every arch other than x86 exposes 
this functionality without the GPL-only restriction. Although IMO 
non-GPL driver developers wouldn't grieve over this particular feature 
simply because pretty much everyone would have to build on x86 and that 
arch wouldn't have it exposed, I do think it will be more demanded on 
loongarch, where HW performance is in general lower than x86/arm64 
offerings at similar cost levels, so perhaps people would have to resort 
to FP/SIMD tricks to reach performance on par with others.

Also, if the old world is taken into consideration (which we normally 
have the luxury of not having to do so), consider Ruoyao's case where a 
commercial partner of Loongson wants to do this with the vendor kernel, 
but the symbols are exported GPL -- in this case I doubt the GPL marking 
will remain, thus creating inconsistency between upstream and vendor 
kernels, and community distros are going to complain loudly about the 
need to patch things. It's probably best to avoid all of this upfront.

Note that this is all suggestion though, it's down to you and your team 
to decide after all. And I've not done the archaeology about the other 
arches' choice yet, which may or may not reveal more reasoning behind 
their status quo.

-- 
WANG "xen0n" Xuerui

Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/