Message ID | 20230301085109.2373524-1-chenhuacai@loongson.cn |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp3515335wrd; Wed, 1 Mar 2023 00:53:47 -0800 (PST) X-Google-Smtp-Source: AK7set8gClHSvK/+fVGdVMQL7D2XJPLEbbA6ssH0E0W0YyFZcIe+aIAtG+9xhmGVxjYCdXDRff1/ X-Received: by 2002:a17:90a:193:b0:22c:aaaf:8dd9 with SMTP id 19-20020a17090a019300b0022caaaf8dd9mr6920414pjc.47.1677660826995; Wed, 01 Mar 2023 00:53:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677660826; cv=none; d=google.com; s=arc-20160816; b=mt0wiXhI/J09rkQUFbEu5ZhWyeojIqSj/tXQFHJmn9lXnw9RK8VYz/oG7CddbKl8C7 S1Nz2Em5AaJTJC7QHwDqZKgLbI9Je0i022v0kgtrwU81bEarnVzJBKzxIYJwmoGCnmAf TrkcMaa0TnD8bC9q/P1I9jSm2k0hB4Ho2xU/v8YqzcXGMx2wmGlLjBvlf5Jez/4IyARy Ik7nare1g22gzfIff/zOmmpE3boTHIJXFfVIjqg7Vujig7k68KY+iq8+2OJW8ip6/QYQ teS5itRl4ZXWXcXf6tMn6b6hvPLlaZFsR8QjspWIZaHSXsXdqhm09c7e9wXySd0pjhux Jy6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=q2lOwYqfSaFxjrw6EsrGS3dr8LFQXfRFfITfLJ8My2Y=; b=ivIb7YHwDatxld+dBZTbT9CeB2P+1kzqabIrf1TX5+fwI4pRnbazsHr+adzEruVjT0 g9AEWrZjgLespT57ZUDysV1umUXeNgTLWO6YJPAFHM9MvIiJ/4brL7kdGC43bnWWXHvF L9AfkP2at4X+Lilet4jdUdN1U2UMVRleUTkZNvHeWnlY/sqvKE/xr909c++fK3LmsUWz IFFRqBVcLJ9+XY1NA2emgSeSHORahC+/Kayv9KVeBoJNFGiAta8Y6/iSwbgbf7qFx+lK ac3q+ifRoWq5A4g8zaUJOiX6BfzoJ3ISzG7lg8ycrBZm8Oqb9p7RJKI6B610DSO6ikZ4 tY6w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b11-20020a63d80b000000b004fb3383abb2si11511358pgh.462.2023.03.01.00.53.33; Wed, 01 Mar 2023 00:53:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229585AbjCAIv1 (ORCPT <rfc822;dipsyhu@gmail.com> + 99 others); Wed, 1 Mar 2023 03:51:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44728 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229480AbjCAIvZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 1 Mar 2023 03:51:25 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9AA7C39BA3; Wed, 1 Mar 2023 00:51:24 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0DDE3611B6; Wed, 1 Mar 2023 08:51:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CDE49C433D2; Wed, 1 Mar 2023 08:51:20 +0000 (UTC) From: Huacai Chen <chenhuacai@loongson.cn> To: Arnd Bergmann <arnd@arndb.de>, Huacai Chen <chenhuacai@kernel.org> Cc: loongarch@lists.linux.dev, linux-arch@vger.kernel.org, Xuefeng Li <lixuefeng@loongson.cn>, Guo Ren <guoren@kernel.org>, Xuerui Wang <kernel@xen0n.name>, Jiaxun Yang <jiaxun.yang@flygoat.com>, linux-kernel@vger.kernel.org, loongson-kernel@lists.loongnix.cn, Huacai Chen <chenhuacai@loongson.cn> Subject: [PATCH] LoongArch: Export some symbols without GPL Date: Wed, 1 Mar 2023 16:51:09 +0800 Message-Id: <20230301085109.2373524-1-chenhuacai@loongson.cn> X-Mailer: git-send-email 2.39.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759154879185640597?= X-GMAIL-MSGID: =?utf-8?q?1759154879185640597?= |
Series |
LoongArch: Export some symbols without GPL
|
|
Commit Message
Huacai Chen
March 1, 2023, 8:51 a.m. UTC
Some symbols, i.e., vm_map_base, empty_zero_page and invalid_pmd_table,
could be accessed widely by some out-of-tree non-GPL but important file
systems or drivers (e.g., OpenZFS). Let's use EXPORT_SYMBOL() instead of
EXPORT_SYMBOL_GPL() to export them, so as to avoid build errors.
Details about vm_map_base: may be referenced through macros PCI_IOBASE,
VMALLOC_START and VMALLOC_END.
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
---
arch/loongarch/kernel/cpu-probe.c | 2 +-
arch/loongarch/mm/init.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
Comments
Hi, On 2023/3/1 16:51, Huacai Chen wrote: > Some symbols, i.e., vm_map_base, empty_zero_page and invalid_pmd_table, > could be accessed widely by some out-of-tree non-GPL but important file > systems or drivers (e.g., OpenZFS). Let's use EXPORT_SYMBOL() instead of > EXPORT_SYMBOL_GPL() to export them, so as to avoid build errors. The commit title probably could become "Mark 3 symbol exports as non-GPL". Also you could drop the "some symbols, i.e.," part and go straight to the 3 symbols. It sounds more natural to me at least (because I know the current wording is 1:1 perfectly idiomatic Chinese, so it is highly likely some adjustment would be needed: idiomatic English don't *perfectly* map to Chinese). In addition to this, I've did some archaeology: In the OpenZFS case, empty_zero_page and vm_map_base are affected. vm_map_base is arch/loongarch invention so we actually kind of have "authority" over it, but what follows is a little more background on why EXPORT_SYMBOL is arguably more appropriate for empty_zero_page. As it stands today, only 3 architectures export empty_zero_page as a GPL symbol: ia64, loongarch and mips. loongarch gets the GPL export by inheriting from mips, and the mips export was first introduced in commit 497d2adcbf50b ("[MIPS] Export empty_zero_page for sake of the ext4 module."). The ia64 export was similar: commit a7d57ecf4216e ("[IA64] Export three symbols for module use") did so for kvm. In both ia64 and mips, the export of empty_zero_page was done for satisfying some in-kernel component built as module (kvm and ext4 respectively), and given its reasonably low-level nature, GPL is a reasonable choice. But looking at the bigger picture it is evident most other architectures do not regard it as GPL, so in effect the symbol probably should not be treated as such, in favor of consistency. You could incorporate some or all of this into the commit message to give others some background on the justification. After all reverting symbols to non-GPL is relatively rare compared to all the GPL-marking actions. > > Details about vm_map_base: may be referenced through macros PCI_IOBASE, > VMALLOC_START and VMALLOC_END. > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> > --- > arch/loongarch/kernel/cpu-probe.c | 2 +- > arch/loongarch/mm/init.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/loongarch/kernel/cpu-probe.c b/arch/loongarch/kernel/cpu-probe.c > index 008b0249905f..001e43dd94ca 100644 > --- a/arch/loongarch/kernel/cpu-probe.c > +++ b/arch/loongarch/kernel/cpu-probe.c > @@ -60,7 +60,7 @@ static inline void set_elf_platform(int cpu, const char *plat) > > /* MAP BASE */ > unsigned long vm_map_base; > -EXPORT_SYMBOL_GPL(vm_map_base); > +EXPORT_SYMBOL(vm_map_base); > > static void cpu_probe_addrbits(struct cpuinfo_loongarch *c) > { > diff --git a/arch/loongarch/mm/init.c b/arch/loongarch/mm/init.c > index e018aed34586..3b7d8129570b 100644 > --- a/arch/loongarch/mm/init.c > +++ b/arch/loongarch/mm/init.c > @@ -41,7 +41,7 @@ > * don't have to care about aliases on other CPUs. > */ > unsigned long empty_zero_page, zero_page_mask; > -EXPORT_SYMBOL_GPL(empty_zero_page); > +EXPORT_SYMBOL(empty_zero_page); > EXPORT_SYMBOL(zero_page_mask); > > void setup_zero_pages(void) > @@ -270,7 +270,7 @@ pud_t invalid_pud_table[PTRS_PER_PUD] __page_aligned_bss; > #endif > #ifndef __PAGETABLE_PMD_FOLDED > pmd_t invalid_pmd_table[PTRS_PER_PMD] __page_aligned_bss; > -EXPORT_SYMBOL_GPL(invalid_pmd_table); > +EXPORT_SYMBOL(invalid_pmd_table); > #endif > pte_t invalid_pte_table[PTRS_PER_PTE] __page_aligned_bss; > EXPORT_SYMBOL(invalid_pte_table); And in the latter two cases it seems we're actually fixing inconsistencies. Nice! Reviewed-by: WANG Xuerui <git@xen0n.name>
Hi, Xuerui, On Wed, Mar 1, 2023 at 6:07 PM WANG Xuerui <kernel@xen0n.name> wrote: > > Hi, > > On 2023/3/1 16:51, Huacai Chen wrote: > > Some symbols, i.e., vm_map_base, empty_zero_page and invalid_pmd_table, > > could be accessed widely by some out-of-tree non-GPL but important file > > systems or drivers (e.g., OpenZFS). Let's use EXPORT_SYMBOL() instead of > > EXPORT_SYMBOL_GPL() to export them, so as to avoid build errors. > > The commit title probably could become "Mark 3 symbol exports as non-GPL". > > Also you could drop the "some symbols, i.e.," part and go straight to > the 3 symbols. It sounds more natural to me at least (because I know the > current wording is 1:1 perfectly idiomatic Chinese, so it is highly > likely some adjustment would be needed: idiomatic English don't > *perfectly* map to Chinese). > > In addition to this, I've did some archaeology: > > In the OpenZFS case, empty_zero_page and vm_map_base are affected. > vm_map_base is arch/loongarch invention so we actually kind of have > "authority" over it, but what follows is a little more background on why > EXPORT_SYMBOL is arguably more appropriate for empty_zero_page. > > As it stands today, only 3 architectures export empty_zero_page as a GPL > symbol: ia64, loongarch and mips. loongarch gets the GPL export by > inheriting from mips, and the mips export was first introduced in commit > 497d2adcbf50b ("[MIPS] Export empty_zero_page for sake of the ext4 > module."). The ia64 export was similar: commit a7d57ecf4216e ("[IA64] > Export three symbols for module use") did so for kvm. > > In both ia64 and mips, the export of empty_zero_page was done for > satisfying some in-kernel component built as module (kvm and ext4 > respectively), and given its reasonably low-level nature, GPL is a > reasonable choice. But looking at the bigger picture it is evident most > other architectures do not regard it as GPL, so in effect the symbol > probably should not be treated as such, in favor of consistency. > > You could incorporate some or all of this into the commit message to > give others some background on the justification. After all reverting > symbols to non-GPL is relatively rare compared to all the GPL-marking > actions. Thank you very much for giving so many backgrounds, I will update the commit message. Huacai > > > > > Details about vm_map_base: may be referenced through macros PCI_IOBASE, > > VMALLOC_START and VMALLOC_END. > > > > Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> > > --- > > arch/loongarch/kernel/cpu-probe.c | 2 +- > > arch/loongarch/mm/init.c | 4 ++-- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/arch/loongarch/kernel/cpu-probe.c b/arch/loongarch/kernel/cpu-probe.c > > index 008b0249905f..001e43dd94ca 100644 > > --- a/arch/loongarch/kernel/cpu-probe.c > > +++ b/arch/loongarch/kernel/cpu-probe.c > > @@ -60,7 +60,7 @@ static inline void set_elf_platform(int cpu, const char *plat) > > > > /* MAP BASE */ > > unsigned long vm_map_base; > > -EXPORT_SYMBOL_GPL(vm_map_base); > > +EXPORT_SYMBOL(vm_map_base); > > > > static void cpu_probe_addrbits(struct cpuinfo_loongarch *c) > > { > > diff --git a/arch/loongarch/mm/init.c b/arch/loongarch/mm/init.c > > index e018aed34586..3b7d8129570b 100644 > > --- a/arch/loongarch/mm/init.c > > +++ b/arch/loongarch/mm/init.c > > @@ -41,7 +41,7 @@ > > * don't have to care about aliases on other CPUs. > > */ > > unsigned long empty_zero_page, zero_page_mask; > > -EXPORT_SYMBOL_GPL(empty_zero_page); > > +EXPORT_SYMBOL(empty_zero_page); > > EXPORT_SYMBOL(zero_page_mask); > > > > void setup_zero_pages(void) > > @@ -270,7 +270,7 @@ pud_t invalid_pud_table[PTRS_PER_PUD] __page_aligned_bss; > > #endif > > #ifndef __PAGETABLE_PMD_FOLDED > > pmd_t invalid_pmd_table[PTRS_PER_PMD] __page_aligned_bss; > > -EXPORT_SYMBOL_GPL(invalid_pmd_table); > > +EXPORT_SYMBOL(invalid_pmd_table); > > #endif > > pte_t invalid_pte_table[PTRS_PER_PTE] __page_aligned_bss; > > EXPORT_SYMBOL(invalid_pte_table); > > And in the latter two cases it seems we're actually fixing > inconsistencies. Nice! > > Reviewed-by: WANG Xuerui <git@xen0n.name> > > -- > WANG "xen0n" Xuerui > > Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/ > >
diff --git a/arch/loongarch/kernel/cpu-probe.c b/arch/loongarch/kernel/cpu-probe.c index 008b0249905f..001e43dd94ca 100644 --- a/arch/loongarch/kernel/cpu-probe.c +++ b/arch/loongarch/kernel/cpu-probe.c @@ -60,7 +60,7 @@ static inline void set_elf_platform(int cpu, const char *plat) /* MAP BASE */ unsigned long vm_map_base; -EXPORT_SYMBOL_GPL(vm_map_base); +EXPORT_SYMBOL(vm_map_base); static void cpu_probe_addrbits(struct cpuinfo_loongarch *c) { diff --git a/arch/loongarch/mm/init.c b/arch/loongarch/mm/init.c index e018aed34586..3b7d8129570b 100644 --- a/arch/loongarch/mm/init.c +++ b/arch/loongarch/mm/init.c @@ -41,7 +41,7 @@ * don't have to care about aliases on other CPUs. */ unsigned long empty_zero_page, zero_page_mask; -EXPORT_SYMBOL_GPL(empty_zero_page); +EXPORT_SYMBOL(empty_zero_page); EXPORT_SYMBOL(zero_page_mask); void setup_zero_pages(void) @@ -270,7 +270,7 @@ pud_t invalid_pud_table[PTRS_PER_PUD] __page_aligned_bss; #endif #ifndef __PAGETABLE_PMD_FOLDED pmd_t invalid_pmd_table[PTRS_PER_PMD] __page_aligned_bss; -EXPORT_SYMBOL_GPL(invalid_pmd_table); +EXPORT_SYMBOL(invalid_pmd_table); #endif pte_t invalid_pte_table[PTRS_PER_PTE] __page_aligned_bss; EXPORT_SYMBOL(invalid_pte_table);