[PATCH v2] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES

[PATCH v2] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES

[Vlastimil Babka]

Christoph suggested that the explicit _GPL_ can be dropped from the
module namespace export macro, as it's intended for in-tree modules
only. It would be possible to resrict it technically, but it was pointed
out [2] that some cases of using an out-of-tree build of an in-tree
module with the same name are legitimate. But in that case those also
have to be GPL anyway so it's unnecessary to spell it out.

Link: https://lore.kernel.org/all/aFleJN_fE-RbSoFD@infradead.org/ [1]
Link: https://lore.kernel.org/all/CAK7LNATRkZHwJGpojCnvdiaoDnP%2BaeUXgdey5sb_8muzdWTMkA@mail.gmail.com/ [2]
Suggested-by: Christoph Hellwig <hch@infradead.org>
Reviewed-by: Shivank Garg <shivankg@amd.com>
Acked-by: Christian Brauner <brauner@kernel.org>
Acked-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
Christian asked [1] for EXPORT_SYMBOL_FOR_MODULES() without the _GPL_
part to avoid controversy converting selected existing EXPORT_SYMBOL().
Christoph argued [2] that the _FOR_MODULES() export is intended for
in-tree modules and thus GPL is implied anyway and can be simply dropped
from the export macro name. Peter agreed [3] about the intention for
in-tree modules only, although nothing currently enforces it.

It seemed straightforward to add this enforcement, so v1 did that. But
there were concerns of breaking the (apparently legitimate) usecases of
loading an updated/development out of tree built version of an in-tree
module.

So leave out the enforcement part and just drop the _GPL_ from the
export macro name and so we're left with EXPORT_SYMBOL_FOR_MODULES()
only. Any in-tree module used in an out-of-tree way will have to be GPL
anyway by definition.

Current -next has some new instances of EXPORT_SYMBOL_GPL_FOR_MODULES()
in drivers/tty/serial/8250/8250_rsa.c by commit b20d6576cdb3 ("serial:
8250: export RSA functions"). Hopefully it's resolvable by a merge
commit fixup and we don't need to provide a temporary alias.

[1] https://lore.kernel.org/all/20250623-warmwasser-giftig-ff656fce89ad@brauner/
[2] https://lore.kernel.org/all/aFleJN_fE-RbSoFD@infradead.org/
[3] https://lore.kernel.org/all/20250623142836.GT1613200@noisy.programming.kicks-ass.net/
---
Changes in v2:
- drop the patch to restrict module namespace export for in-tree modules
- fix a pre-existing documentation typo (Nicolas Schier)
- Link to v1: https://patch.msgid.link/20250708-export_modules-v1-0-fbf7a282d23f@suse.cz
---
 Documentation/core-api/symbol-namespaces.rst | 8 ++++----
 fs/anon_inodes.c                             | 2 +-
 include/linux/export.h                       | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/core-api/symbol-namespaces.rst b/Documentation/core-api/symbol-namespaces.rst
index 32fc73dc5529e8844c2ce2580987155bcd13cd09..6f7f4f47d43cdeb3b5008c795d254ca2661d39a6 100644
--- a/Documentation/core-api/symbol-namespaces.rst
+++ b/Documentation/core-api/symbol-namespaces.rst
@@ -76,8 +76,8 @@ A second option to define the default namespace is directly in the compilation
 within the corresponding compilation unit before the #include for
 <linux/export.h>. Typically it's placed before the first #include statement.
 
-Using the EXPORT_SYMBOL_GPL_FOR_MODULES() macro
------------------------------------------------
+Using the EXPORT_SYMBOL_FOR_MODULES() macro
+-------------------------------------------
 
 Symbols exported using this macro are put into a module namespace. This
 namespace cannot be imported.
@@ -87,9 +87,9 @@ modules to access this symbol. Simple tail-globs are supported.
 
 For example::
 
-  EXPORT_SYMBOL_GPL_FOR_MODULES(preempt_notifier_inc, "kvm,kvm-*")
+  EXPORT_SYMBOL_FOR_MODULES(preempt_notifier_inc, "kvm,kvm-*")
 
-will limit usage of this symbol to modules whoes name matches the given
+will limit usage of this symbol to modules whose name matches the given
 patterns.
 
 How to use Symbols exported in Namespaces
diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
index 1d847a939f29a41356af3f12e5f61372ec2fb550..180a458fc4f74249d674ec3c6e01277df1d9e743 100644
--- a/fs/anon_inodes.c
+++ b/fs/anon_inodes.c
@@ -129,7 +129,7 @@ struct inode *anon_inode_make_secure_inode(struct super_block *sb, const char *n
 	}
 	return inode;
 }
-EXPORT_SYMBOL_GPL_FOR_MODULES(anon_inode_make_secure_inode, "kvm");
+EXPORT_SYMBOL_FOR_MODULES(anon_inode_make_secure_inode, "kvm");
 
 static struct file *__anon_inode_getfile(const char *name,
 					 const struct file_operations *fops,
diff --git a/include/linux/export.h b/include/linux/export.h
index f35d03b4113b19798036d2993d67eb932ad8ce6f..a686fd0ba406509da5f397e3a415d05c5a051c0d 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -91,6 +91,6 @@
 #define EXPORT_SYMBOL_NS(sym, ns)	__EXPORT_SYMBOL(sym, "", ns)
 #define EXPORT_SYMBOL_NS_GPL(sym, ns)	__EXPORT_SYMBOL(sym, "GPL", ns)
 
-#define EXPORT_SYMBOL_GPL_FOR_MODULES(sym, mods) __EXPORT_SYMBOL(sym, "GPL", "module:" mods)
+#define EXPORT_SYMBOL_FOR_MODULES(sym, mods) __EXPORT_SYMBOL(sym, "GPL", "module:" mods)
 
 #endif /* _LINUX_EXPORT_H */

---
base-commit: d7b8f8e20813f0179d8ef519541a3527e7661d3a
change-id: 20250708-export_modules-12908fa41006

Best regards,
-- 
Vlastimil Babka <vbabka@suse.cz>

Re: [PATCH v2] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES

[Nicolas Schier]

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

On Fri, Jul 11, 2025 at 04:05:16PM +0200, Vlastimil Babka wrote:
> Christoph suggested that the explicit _GPL_ can be dropped from the
> module namespace export macro, as it's intended for in-tree modules
> only. It would be possible to resrict it technically, but it was pointed

s/resrict/restrict/

> out [2] that some cases of using an out-of-tree build of an in-tree
> module with the same name are legitimate. But in that case those also
> have to be GPL anyway so it's unnecessary to spell it out.
> 
> Link: https://lore.kernel.org/all/aFleJN_fE-RbSoFD@infradead.org/ [1]
> Link: https://lore.kernel.org/all/CAK7LNATRkZHwJGpojCnvdiaoDnP%2BaeUXgdey5sb_8muzdWTMkA@mail.gmail.com/ [2]
> Suggested-by: Christoph Hellwig <hch@infradead.org>
> Reviewed-by: Shivank Garg <shivankg@amd.com>
> Acked-by: Christian Brauner <brauner@kernel.org>
> Acked-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> ---

Looks good to me, thanks!

Acked-by: Nicolas Schier <n.schier@avm.de>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v2] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES

[Daniel Gomez]

On 11/07/2025 16.05, Vlastimil Babka wrote:
> Christoph suggested that the explicit _GPL_ can be dropped from the
> module namespace export macro, as it's intended for in-tree modules
> only. It would be possible to resrict it technically, but it was pointed
> out [2] that some cases of using an out-of-tree build of an in-tree
> module with the same name are legitimate. But in that case those also
> have to be GPL anyway so it's unnecessary to spell it out.
> 
> Link: https://lore.kernel.org/all/aFleJN_fE-RbSoFD@infradead.org/ [1]
> Link: https://lore.kernel.org/all/CAK7LNATRkZHwJGpojCnvdiaoDnP%2BaeUXgdey5sb_8muzdWTMkA@mail.gmail.com/ [2]
> Suggested-by: Christoph Hellwig <hch@infradead.org>
> Reviewed-by: Shivank Garg <shivankg@amd.com>
> Acked-by: Christian Brauner <brauner@kernel.org>
> Acked-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> ---
> Christian asked [1] for EXPORT_SYMBOL_FOR_MODULES() without the _GPL_
> part to avoid controversy converting selected existing EXPORT_SYMBOL().
> Christoph argued [2] that the _FOR_MODULES() export is intended for
> in-tree modules and thus GPL is implied anyway and can be simply dropped
> from the export macro name. Peter agreed [3] about the intention for
> in-tree modules only, although nothing currently enforces it.
> 
> It seemed straightforward to add this enforcement, so v1 did that. But
> there were concerns of breaking the (apparently legitimate) usecases of
> loading an updated/development out of tree built version of an in-tree
> module.
> 
> So leave out the enforcement part and just drop the _GPL_ from the
> export macro name and so we're left with EXPORT_SYMBOL_FOR_MODULES()
> only. Any in-tree module used in an out-of-tree way will have to be GPL
> anyway by definition.
> 
> Current -next has some new instances of EXPORT_SYMBOL_GPL_FOR_MODULES()
> in drivers/tty/serial/8250/8250_rsa.c by commit b20d6576cdb3 ("serial:
> 8250: export RSA functions"). Hopefully it's resolvable by a merge
> commit fixup and we don't need to provide a temporary alias.
> 
> [1] https://lore.kernel.org/all/20250623-warmwasser-giftig-ff656fce89ad@brauner/
> [2] https://lore.kernel.org/all/aFleJN_fE-RbSoFD@infradead.org/
> [3] https://lore.kernel.org/all/20250623142836.GT1613200@noisy.programming.kicks-ass.net/
> ---
> Changes in v2:
> - drop the patch to restrict module namespace export for in-tree modules
> - fix a pre-existing documentation typo (Nicolas Schier)
> - Link to v1: https://patch.msgid.link/20250708-export_modules-v1-0-fbf7a282d23f@suse.cz
> ---
>  Documentation/core-api/symbol-namespaces.rst | 8 ++++----
>  fs/anon_inodes.c                             | 2 +-
>  include/linux/export.h                       | 2 +-
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/core-api/symbol-namespaces.rst b/Documentation/core-api/symbol-namespaces.rst
> index 32fc73dc5529e8844c2ce2580987155bcd13cd09..6f7f4f47d43cdeb3b5008c795d254ca2661d39a6 100644
> --- a/Documentation/core-api/symbol-namespaces.rst
> +++ b/Documentation/core-api/symbol-namespaces.rst
> @@ -76,8 +76,8 @@ A second option to define the default namespace is directly in the compilation
>  within the corresponding compilation unit before the #include for
>  <linux/export.h>. Typically it's placed before the first #include statement.
>  
> -Using the EXPORT_SYMBOL_GPL_FOR_MODULES() macro
> ------------------------------------------------
> +Using the EXPORT_SYMBOL_FOR_MODULES() macro
> +-------------------------------------------
>  
>  Symbols exported using this macro are put into a module namespace. This
>  namespace cannot be imported.

The new naming makes sense, but it breaks the pattern with _GPL suffix:

* EXPORT_SYMBOL(sym)
* EXPORT_SYMBOL_GPL(sym)
* EXPORT_SYMBOL_NS(sym, ns)
* EXPORT_SYMBOL_NS_GPL(sym, ns)
* EXPORT_SYMBOL_FOR_MODULES(sym, mods)

So I think when reading this one may forget about the _obvious_ reason. That's
why I think clarifying that in the documentation would be great. Something like:

Symbols exported using this macro are put into a module namespace. This
namespace cannot be imported. And it's implicitly GPL-only as it's only intended
for in-tree modules.

Other than that, it looks good.

Reviewed-by: Daniel Gomez <da.gomez@samsung.com>

Re: [PATCH v2] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES

[Greg Kroah-Hartman]

On Sat, Jul 12, 2025 at 08:26:17PM +0200, Daniel Gomez wrote:
> On 11/07/2025 16.05, Vlastimil Babka wrote:
> > Christoph suggested that the explicit _GPL_ can be dropped from the
> > module namespace export macro, as it's intended for in-tree modules
> > only. It would be possible to resrict it technically, but it was pointed
> > out [2] that some cases of using an out-of-tree build of an in-tree
> > module with the same name are legitimate. But in that case those also
> > have to be GPL anyway so it's unnecessary to spell it out.
> > 
> > Link: https://lore.kernel.org/all/aFleJN_fE-RbSoFD@infradead.org/ [1]
> > Link: https://lore.kernel.org/all/CAK7LNATRkZHwJGpojCnvdiaoDnP%2BaeUXgdey5sb_8muzdWTMkA@mail.gmail.com/ [2]
> > Suggested-by: Christoph Hellwig <hch@infradead.org>
> > Reviewed-by: Shivank Garg <shivankg@amd.com>
> > Acked-by: Christian Brauner <brauner@kernel.org>
> > Acked-by: David Hildenbrand <david@redhat.com>
> > Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> > ---
> > Christian asked [1] for EXPORT_SYMBOL_FOR_MODULES() without the _GPL_
> > part to avoid controversy converting selected existing EXPORT_SYMBOL().
> > Christoph argued [2] that the _FOR_MODULES() export is intended for
> > in-tree modules and thus GPL is implied anyway and can be simply dropped
> > from the export macro name. Peter agreed [3] about the intention for
> > in-tree modules only, although nothing currently enforces it.
> > 
> > It seemed straightforward to add this enforcement, so v1 did that. But
> > there were concerns of breaking the (apparently legitimate) usecases of
> > loading an updated/development out of tree built version of an in-tree
> > module.
> > 
> > So leave out the enforcement part and just drop the _GPL_ from the
> > export macro name and so we're left with EXPORT_SYMBOL_FOR_MODULES()
> > only. Any in-tree module used in an out-of-tree way will have to be GPL
> > anyway by definition.
> > 
> > Current -next has some new instances of EXPORT_SYMBOL_GPL_FOR_MODULES()
> > in drivers/tty/serial/8250/8250_rsa.c by commit b20d6576cdb3 ("serial:
> > 8250: export RSA functions"). Hopefully it's resolvable by a merge
> > commit fixup and we don't need to provide a temporary alias.
> > 
> > [1] https://lore.kernel.org/all/20250623-warmwasser-giftig-ff656fce89ad@brauner/
> > [2] https://lore.kernel.org/all/aFleJN_fE-RbSoFD@infradead.org/
> > [3] https://lore.kernel.org/all/20250623142836.GT1613200@noisy.programming.kicks-ass.net/
> > ---
> > Changes in v2:
> > - drop the patch to restrict module namespace export for in-tree modules
> > - fix a pre-existing documentation typo (Nicolas Schier)
> > - Link to v1: https://patch.msgid.link/20250708-export_modules-v1-0-fbf7a282d23f@suse.cz
> > ---
> >  Documentation/core-api/symbol-namespaces.rst | 8 ++++----
> >  fs/anon_inodes.c                             | 2 +-
> >  include/linux/export.h                       | 2 +-
> >  3 files changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/Documentation/core-api/symbol-namespaces.rst b/Documentation/core-api/symbol-namespaces.rst
> > index 32fc73dc5529e8844c2ce2580987155bcd13cd09..6f7f4f47d43cdeb3b5008c795d254ca2661d39a6 100644
> > --- a/Documentation/core-api/symbol-namespaces.rst
> > +++ b/Documentation/core-api/symbol-namespaces.rst
> > @@ -76,8 +76,8 @@ A second option to define the default namespace is directly in the compilation
> >  within the corresponding compilation unit before the #include for
> >  <linux/export.h>. Typically it's placed before the first #include statement.
> >  
> > -Using the EXPORT_SYMBOL_GPL_FOR_MODULES() macro
> > ------------------------------------------------
> > +Using the EXPORT_SYMBOL_FOR_MODULES() macro
> > +-------------------------------------------
> >  
> >  Symbols exported using this macro are put into a module namespace. This
> >  namespace cannot be imported.
> 
> The new naming makes sense, but it breaks the pattern with _GPL suffix:
> 
> * EXPORT_SYMBOL(sym)
> * EXPORT_SYMBOL_GPL(sym)
> * EXPORT_SYMBOL_NS(sym, ns)
> * EXPORT_SYMBOL_NS_GPL(sym, ns)
> * EXPORT_SYMBOL_FOR_MODULES(sym, mods)
> 
> So I think when reading this one may forget about the _obvious_ reason. That's
> why I think clarifying that in the documentation would be great. Something like:
> 
> Symbols exported using this macro are put into a module namespace. This
> namespace cannot be imported. And it's implicitly GPL-only as it's only intended
> for in-tree modules.

s/implicitly/explicitly/

thanks,

greg k-h

Re: [PATCH v2] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES

[Vlastimil Babka]

On 7/13/25 10:31, Greg Kroah-Hartman wrote:
> On Sat, Jul 12, 2025 at 08:26:17PM +0200, Daniel Gomez wrote:
>> On 11/07/2025 16.05, Vlastimil Babka wrote:
>> > Changes in v2:
>> > - drop the patch to restrict module namespace export for in-tree modules
>> > - fix a pre-existing documentation typo (Nicolas Schier)
>> > - Link to v1: https://patch.msgid.link/20250708-export_modules-v1-0-fbf7a282d23f@suse.cz
>> > ---
>> >  Documentation/core-api/symbol-namespaces.rst | 8 ++++----
>> >  fs/anon_inodes.c                             | 2 +-
>> >  include/linux/export.h                       | 2 +-
>> >  3 files changed, 6 insertions(+), 6 deletions(-)
>> > 
>> > diff --git a/Documentation/core-api/symbol-namespaces.rst b/Documentation/core-api/symbol-namespaces.rst
>> > index 32fc73dc5529e8844c2ce2580987155bcd13cd09..6f7f4f47d43cdeb3b5008c795d254ca2661d39a6 100644
>> > --- a/Documentation/core-api/symbol-namespaces.rst
>> > +++ b/Documentation/core-api/symbol-namespaces.rst
>> > @@ -76,8 +76,8 @@ A second option to define the default namespace is directly in the compilation
>> >  within the corresponding compilation unit before the #include for
>> >  <linux/export.h>. Typically it's placed before the first #include statement.
>> >  
>> > -Using the EXPORT_SYMBOL_GPL_FOR_MODULES() macro
>> > ------------------------------------------------
>> > +Using the EXPORT_SYMBOL_FOR_MODULES() macro
>> > +-------------------------------------------
>> >  
>> >  Symbols exported using this macro are put into a module namespace. This
>> >  namespace cannot be imported.
>> 
>> The new naming makes sense, but it breaks the pattern with _GPL suffix:
>> 
>> * EXPORT_SYMBOL(sym)
>> * EXPORT_SYMBOL_GPL(sym)
>> * EXPORT_SYMBOL_NS(sym, ns)
>> * EXPORT_SYMBOL_NS_GPL(sym, ns)
>> * EXPORT_SYMBOL_FOR_MODULES(sym, mods)
>> 
>> So I think when reading this one may forget about the _obvious_ reason. That's
>> why I think clarifying that in the documentation would be great. Something like:
>> 
>> Symbols exported using this macro are put into a module namespace. This
>> namespace cannot be imported. And it's implicitly GPL-only as it's only intended
>> for in-tree modules.
> 
> s/implicitly/explicitly/

From the point of the macro name,
it was explicit with "EXPORT_SYMBOL_GPL_FOR_MODULES()"
it's implicit with "EXPORT_SYMBOL_FOR_MODULES()"

> thanks,
> 
> greg k-h

Re: [PATCH v2] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES

[Christian Brauner]

On Fri, Jul 11, 2025 at 04:05:16PM +0200, Vlastimil Babka wrote:
> Christoph suggested that the explicit _GPL_ can be dropped from the
> module namespace export macro, as it's intended for in-tree modules
> only. It would be possible to resrict it technically, but it was pointed
> out [2] that some cases of using an out-of-tree build of an in-tree
> module with the same name are legitimate. But in that case those also
> have to be GPL anyway so it's unnecessary to spell it out.
> 
> Link: https://lore.kernel.org/all/aFleJN_fE-RbSoFD@infradead.org/ [1]
> Link: https://lore.kernel.org/all/CAK7LNATRkZHwJGpojCnvdiaoDnP%2BaeUXgdey5sb_8muzdWTMkA@mail.gmail.com/ [2]
> Suggested-by: Christoph Hellwig <hch@infradead.org>
> Reviewed-by: Shivank Garg <shivankg@amd.com>
> Acked-by: Christian Brauner <brauner@kernel.org>
> Acked-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> ---
> Christian asked [1] for EXPORT_SYMBOL_FOR_MODULES() without the _GPL_
> part to avoid controversy converting selected existing EXPORT_SYMBOL().

Thank you!
Reviewed-by: Christian Brauner <brauner@kernel.org>

Am I supposed to take this or how's that going to work?

> Christoph argued [2] that the _FOR_MODULES() export is intended for
> in-tree modules and thus GPL is implied anyway and can be simply dropped
> from the export macro name. Peter agreed [3] about the intention for
> in-tree modules only, although nothing currently enforces it.
> 
> It seemed straightforward to add this enforcement, so v1 did that. But
> there were concerns of breaking the (apparently legitimate) usecases of
> loading an updated/development out of tree built version of an in-tree
> module.
> 
> So leave out the enforcement part and just drop the _GPL_ from the
> export macro name and so we're left with EXPORT_SYMBOL_FOR_MODULES()
> only. Any in-tree module used in an out-of-tree way will have to be GPL
> anyway by definition.
> 
> Current -next has some new instances of EXPORT_SYMBOL_GPL_FOR_MODULES()
> in drivers/tty/serial/8250/8250_rsa.c by commit b20d6576cdb3 ("serial:
> 8250: export RSA functions"). Hopefully it's resolvable by a merge
> commit fixup and we don't need to provide a temporary alias.
> 
> [1] https://lore.kernel.org/all/20250623-warmwasser-giftig-ff656fce89ad@brauner/
> [2] https://lore.kernel.org/all/aFleJN_fE-RbSoFD@infradead.org/
> [3] https://lore.kernel.org/all/20250623142836.GT1613200@noisy.programming.kicks-ass.net/
> ---