[PATCH v3] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES

[PATCH v3] 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 restrict 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 in the
macro name.

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: David Hildenbrand <david@redhat.com>
Acked-by: Nicolas Schier <n.schier@avm.de>
Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
---
Daniel, please clarify if you'll take this via module tree or Christian
can take it via vfs tree?

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 v3:
- Clarified the macro documentation about in-tree intention and GPL
  implications, per Daniel.
- Applied tags.
- Link to v2: https://patch.msgid.link/20250711-export_modules-v2-1-b59b6fad413a@suse.cz

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 | 11 ++++++-----
 fs/anon_inodes.c                             |  2 +-
 include/linux/export.h                       |  2 +-
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/Documentation/core-api/symbol-namespaces.rst b/Documentation/core-api/symbol-namespaces.rst
index 32fc73dc5529e8844c2ce2580987155bcd13cd09..034898e81ba201097330ab9875429e7d3fa30c0f 100644
--- a/Documentation/core-api/symbol-namespaces.rst
+++ b/Documentation/core-api/symbol-namespaces.rst
@@ -76,20 +76,21 @@ 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.
+namespace cannot be imported. These exports are GPL-only as they are only
+intended for in-tree modules.
 
 The macro takes a comma separated list of module names, allowing only those
 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 v3] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES

[Daniel Gomez]

On 15/07/2025 10.43, 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 restrict 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 in the
> macro name.
> 
> 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: David Hildenbrand <david@redhat.com>
> Acked-by: Nicolas Schier <n.schier@avm.de>
> Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
> Reviewed-by: Christian Brauner <brauner@kernel.org>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> ---
> Daniel, please clarify if you'll take this via module tree or Christian
> can take it via vfs tree?

Patch 707f853d7fa3 ("module: Provide EXPORT_SYMBOL_GPL_FOR_MODULES() helper")
from Peter was merged through Masahiro in v6.16-rc1. Since this is a related
fix/rename/cleanup, it'd make sense for it to go through his kbuild tree as
well. Masahiro, please let me know if you'd prefer otherwise. If not, I'll queue
it up in the modules tree.

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

[Vlastimil Babka]

On 7/15/25 20:58, Daniel Gomez wrote:
> On 15/07/2025 10.43, 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 restrict 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 in the
>> macro name.
>> 
>> 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: David Hildenbrand <david@redhat.com>
>> Acked-by: Nicolas Schier <n.schier@avm.de>
>> Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
>> Reviewed-by: Christian Brauner <brauner@kernel.org>
>> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>> ---
>> Daniel, please clarify if you'll take this via module tree or Christian
>> can take it via vfs tree?
> 
> Patch 707f853d7fa3 ("module: Provide EXPORT_SYMBOL_GPL_FOR_MODULES() helper")
> from Peter was merged through Masahiro in v6.16-rc1. Since this is a related
> fix/rename/cleanup, it'd make sense for it to go through his kbuild tree as
> well. Masahiro, please let me know if you'd prefer otherwise. If not, I'll queue
> it up in the modules tree.

Maybe with no reply, you can queue it then?

Thanks,
Vlastimil

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

[Daniel Gomez]

On 21/07/2025 12.40, Vlastimil Babka wrote:
> On 7/15/25 20:58, Daniel Gomez wrote:
>> On 15/07/2025 10.43, 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 restrict 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 in the
>>> macro name.
>>>
>>> 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: David Hildenbrand <david@redhat.com>
>>> Acked-by: Nicolas Schier <n.schier@avm.de>
>>> Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
>>> Reviewed-by: Christian Brauner <brauner@kernel.org>
>>> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>>> ---
>>> Daniel, please clarify if you'll take this via module tree or Christian
>>> can take it via vfs tree?
>>
>> Patch 707f853d7fa3 ("module: Provide EXPORT_SYMBOL_GPL_FOR_MODULES() helper")
>> from Peter was merged through Masahiro in v6.16-rc1. Since this is a related
>> fix/rename/cleanup, it'd make sense for it to go through his kbuild tree as
>> well. Masahiro, please let me know if you'd prefer otherwise. If not, I'll queue
>> it up in the modules tree.
> 
> Maybe with no reply, you can queue it then?

+ Jiri, Stephen and Greg, added to the To: list.

EXPORT_SYMBOL_GPL_FOR_MODULES macro was merged [1] through Masahiro's
pull request in v6.16-rc1. This patch from Vlastimil renames the macro to
EXPORT_SYMBOL_FOR_MODULES. This means Jiri's patch b20d6576cdb3 "serial: 8250:
export RSA functions" will need to be updated accordingly. I'd like like to
know how you prefer to proceed, since it was requested to have this merged as a
fix before Linus releases a new kernel with the former name.

Link: https://lore.kernel.org/all/CAK7LNAQunzxOHR+vMZLf8kqxyRtLx-Z2G2VZquJmndrT9TZjiQ@mail.gmail.com/ [1]


Masahiro, just a heads-up that I plan to merge this through the linux-modules
tree unless you advise otherwise.

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

[Greg Kroah-Hartman]

On Tue, Jul 22, 2025 at 10:26:43AM +0200, Daniel Gomez wrote:
> On 21/07/2025 12.40, Vlastimil Babka wrote:
> > On 7/15/25 20:58, Daniel Gomez wrote:
> >> On 15/07/2025 10.43, 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 restrict 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 in the
> >>> macro name.
> >>>
> >>> 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: David Hildenbrand <david@redhat.com>
> >>> Acked-by: Nicolas Schier <n.schier@avm.de>
> >>> Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
> >>> Reviewed-by: Christian Brauner <brauner@kernel.org>
> >>> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> >>> ---
> >>> Daniel, please clarify if you'll take this via module tree or Christian
> >>> can take it via vfs tree?
> >>
> >> Patch 707f853d7fa3 ("module: Provide EXPORT_SYMBOL_GPL_FOR_MODULES() helper")
> >> from Peter was merged through Masahiro in v6.16-rc1. Since this is a related
> >> fix/rename/cleanup, it'd make sense for it to go through his kbuild tree as
> >> well. Masahiro, please let me know if you'd prefer otherwise. If not, I'll queue
> >> it up in the modules tree.
> > 
> > Maybe with no reply, you can queue it then?
> 
> + Jiri, Stephen and Greg, added to the To: list.
> 
> EXPORT_SYMBOL_GPL_FOR_MODULES macro was merged [1] through Masahiro's
> pull request in v6.16-rc1. This patch from Vlastimil renames the macro to
> EXPORT_SYMBOL_FOR_MODULES. This means Jiri's patch b20d6576cdb3 "serial: 8250:
> export RSA functions" will need to be updated accordingly. I'd like like to
> know how you prefer to proceed, since it was requested to have this merged as a
> fix before Linus releases a new kernel with the former name.

So you want this in 6.16-final?  Ok, do so and then someone needs to fix
up the build breakage in linux-next and in all of the pull requests to
Linus for 6.17-rc1 :)

> Link: https://lore.kernel.org/all/CAK7LNAQunzxOHR+vMZLf8kqxyRtLx-Z2G2VZquJmndrT9TZjiQ@mail.gmail.com/ [1]
> 
> 
> Masahiro, just a heads-up that I plan to merge this through the linux-modules
> tree unless you advise otherwise.

Why not just do the rename after 6.17-rc1 is out?  That way all new
users will be able to be caught at that point in time.  There's no issue
with the name being as it is for 6.16-final that I can determine, right?

thanks,

greg k-h

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

[Vlastimil Babka]

On 7/22/25 10:46, Greg Kroah-Hartman wrote:
> On Tue, Jul 22, 2025 at 10:26:43AM +0200, Daniel Gomez wrote:
>> > 
>> > Maybe with no reply, you can queue it then?
>> 
>> + Jiri, Stephen and Greg, added to the To: list.
>> 
>> EXPORT_SYMBOL_GPL_FOR_MODULES macro was merged [1] through Masahiro's
>> pull request in v6.16-rc1. This patch from Vlastimil renames the macro to
>> EXPORT_SYMBOL_FOR_MODULES. This means Jiri's patch b20d6576cdb3 "serial: 8250:
>> export RSA functions" will need to be updated accordingly. I'd like like to
>> know how you prefer to proceed, since it was requested to have this merged as a
>> fix before Linus releases a new kernel with the former name.
> 
> So you want this in 6.16-final?  Ok, do so and then someone needs to fix
> up the build breakage in linux-next and in all of the pull requests to
> Linus for 6.17-rc1 :)
> 
>> Link: https://lore.kernel.org/all/CAK7LNAQunzxOHR+vMZLf8kqxyRtLx-Z2G2VZquJmndrT9TZjiQ@mail.gmail.com/ [1]
>> 
>> 
>> Masahiro, just a heads-up that I plan to merge this through the linux-modules
>> tree unless you advise otherwise.
> 
> Why not just do the rename after 6.17-rc1 is out?  That way all new
> users will be able to be caught at that point in time.  There's no issue

Hm there might be people basing their new exports for 6.18 on 6.17-rc1. They
would have to be told to use rc2 then. Maybe the best way would be if Linus
did this just before tagging rc1, while fixing up all users merged during
the merge window?

> with the name being as it is for 6.16-final that I can determine, right?
> 
> thanks,
> 
> greg k-h

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

[Greg Kroah-Hartman]

On Tue, Jul 22, 2025 at 10:49:48AM +0200, Vlastimil Babka wrote:
> On 7/22/25 10:46, Greg Kroah-Hartman wrote:
> > On Tue, Jul 22, 2025 at 10:26:43AM +0200, Daniel Gomez wrote:
> >> > 
> >> > Maybe with no reply, you can queue it then?
> >> 
> >> + Jiri, Stephen and Greg, added to the To: list.
> >> 
> >> EXPORT_SYMBOL_GPL_FOR_MODULES macro was merged [1] through Masahiro's
> >> pull request in v6.16-rc1. This patch from Vlastimil renames the macro to
> >> EXPORT_SYMBOL_FOR_MODULES. This means Jiri's patch b20d6576cdb3 "serial: 8250:
> >> export RSA functions" will need to be updated accordingly. I'd like like to
> >> know how you prefer to proceed, since it was requested to have this merged as a
> >> fix before Linus releases a new kernel with the former name.
> > 
> > So you want this in 6.16-final?  Ok, do so and then someone needs to fix
> > up the build breakage in linux-next and in all of the pull requests to
> > Linus for 6.17-rc1 :)
> > 
> >> Link: https://lore.kernel.org/all/CAK7LNAQunzxOHR+vMZLf8kqxyRtLx-Z2G2VZquJmndrT9TZjiQ@mail.gmail.com/ [1]
> >> 
> >> 
> >> Masahiro, just a heads-up that I plan to merge this through the linux-modules
> >> tree unless you advise otherwise.
> > 
> > Why not just do the rename after 6.17-rc1 is out?  That way all new
> > users will be able to be caught at that point in time.  There's no issue
> 
> Hm there might be people basing their new exports for 6.18 on 6.17-rc1. They
> would have to be told to use rc2 then.

Yes, that's normal, nothing wrong with that at all, we make api name
changes across the tree quite often (i.e. almost every-other release.)

> Maybe the best way would be if Linus
> did this just before tagging rc1, while fixing up all users merged during
> the merge window?

Again, what's wrong with -rc2?  Anyone caught using this on only -rc1
will get a quick "this broke the build" report in linux-next so it's not
like this is going to be unnoticed at all.

thanks,

greg k-h

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

[Daniel Gomez]

On 22/07/2025 10.53, Greg Kroah-Hartman wrote:
> On Tue, Jul 22, 2025 at 10:49:48AM +0200, Vlastimil Babka wrote:
>> On 7/22/25 10:46, Greg Kroah-Hartman wrote:
>>> On Tue, Jul 22, 2025 at 10:26:43AM +0200, Daniel Gomez wrote:
>>>>>
>>>>> Maybe with no reply, you can queue it then?
>>>>
>>>> + Jiri, Stephen and Greg, added to the To: list.
>>>>
>>>> EXPORT_SYMBOL_GPL_FOR_MODULES macro was merged [1] through Masahiro's
>>>> pull request in v6.16-rc1. This patch from Vlastimil renames the macro to
>>>> EXPORT_SYMBOL_FOR_MODULES. This means Jiri's patch b20d6576cdb3 "serial: 8250:
>>>> export RSA functions" will need to be updated accordingly. I'd like like to
>>>> know how you prefer to proceed, since it was requested to have this merged as a
>>>> fix before Linus releases a new kernel with the former name.
>>>
>>> So you want this in 6.16-final?  Ok, do so and then someone needs to fix
>>> up the build breakage in linux-next and in all of the pull requests to
>>> Linus for 6.17-rc1 :)
>>>

I see... that doesn't sound like it was the right approach. I didn't expect
follow-up fixes to be needed for the next merge window. Thanks for the heads-up.
I'll hold off on merging this for now.

>>>> Link: https://lore.kernel.org/all/CAK7LNAQunzxOHR+vMZLf8kqxyRtLx-Z2G2VZquJmndrT9TZjiQ@mail.gmail.com/ [1]
>>>>
>>>>
>>>> Masahiro, just a heads-up that I plan to merge this through the linux-modules
>>>> tree unless you advise otherwise.
>>>
>>> Why not just do the rename after 6.17-rc1 is out?  That way all new
>>> users will be able to be caught at that point in time.  There's no issue
>>
>> Hm there might be people basing their new exports for 6.18 on 6.17-rc1. They
>> would have to be told to use rc2 then.
> 
> Yes, that's normal, nothing wrong with that at all, we make api name
> changes across the tree quite often (i.e. almost every-other release.)
> 
>> Maybe the best way would be if Linus
>> did this just before tagging rc1, while fixing up all users merged during
>> the merge window?
> 
> Again, what's wrong with -rc2?  Anyone caught using this on only -rc1
> will get a quick "this broke the build" report in linux-next so it's not
> like this is going to be unnoticed at all.

I think Christian had some renaming candidates. Christian, does this work for
you?