[PATCH v4] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES

[PATCH v4] 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>
---
In v3, Greg suggested [0] applying after 6.17-rc1. At this moment I can
see all new users of EXPORT_SYMBOL_GPL_FOR_MODULES() pending for 6.17
were merged already and nothing more is in next-20250808. Thus this
rebased version renames all usages. If we merge this before rc1 then
people basing their branches with more new usages (AFAIK KVM might be)
on rc1 will be covered. If this is merged after rc1, they will have to
rebase, as Greg said. I guess it's up to Linus and Daniel.

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.

[0] https://lore.kernel.org/all/2025072219-dollhouse-margarita-de67@gregkh/
[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 v4:
- rebase to current mainline, rename new usages in drivers/tty/serial/8250/8250_rsa.c
- Link to v3: https://patch.msgid.link/20250715-export_modules-v3-1-11fffc67dff7@suse.cz

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 ++++++-----
 drivers/tty/serial/8250/8250_rsa.c           |  8 ++++----
 fs/anon_inodes.c                             |  2 +-
 include/linux/export.h                       |  2 +-
 4 files changed, 12 insertions(+), 11 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/drivers/tty/serial/8250/8250_rsa.c b/drivers/tty/serial/8250/8250_rsa.c
index d34093cc03ad9407f7117dda49554625c14e019a..12a65b79583c03e73bd8f3439b8b541c027f242f 100644
--- a/drivers/tty/serial/8250/8250_rsa.c
+++ b/drivers/tty/serial/8250/8250_rsa.c
@@ -147,7 +147,7 @@ void rsa_enable(struct uart_8250_port *up)
 	if (up->port.uartclk == SERIAL_RSA_BAUD_BASE * 16)
 		serial_out(up, UART_RSA_FRR, 0);
 }
-EXPORT_SYMBOL_GPL_FOR_MODULES(rsa_enable, "8250_base");
+EXPORT_SYMBOL_FOR_MODULES(rsa_enable, "8250_base");
 
 /*
  * Attempts to turn off the RSA FIFO and resets the RSA board back to 115kbps compat mode. It is
@@ -179,7 +179,7 @@ void rsa_disable(struct uart_8250_port *up)
 		up->port.uartclk = SERIAL_RSA_BAUD_BASE_LO * 16;
 	uart_port_unlock_irq(&up->port);
 }
-EXPORT_SYMBOL_GPL_FOR_MODULES(rsa_disable, "8250_base");
+EXPORT_SYMBOL_FOR_MODULES(rsa_disable, "8250_base");
 
 void rsa_autoconfig(struct uart_8250_port *up)
 {
@@ -192,7 +192,7 @@ void rsa_autoconfig(struct uart_8250_port *up)
 	if (__rsa_enable(up))
 		up->port.type = PORT_RSA;
 }
-EXPORT_SYMBOL_GPL_FOR_MODULES(rsa_autoconfig, "8250_base");
+EXPORT_SYMBOL_FOR_MODULES(rsa_autoconfig, "8250_base");
 
 void rsa_reset(struct uart_8250_port *up)
 {
@@ -201,7 +201,7 @@ void rsa_reset(struct uart_8250_port *up)
 
 	serial_out(up, UART_RSA_FRR, 0);
 }
-EXPORT_SYMBOL_GPL_FOR_MODULES(rsa_reset, "8250_base");
+EXPORT_SYMBOL_FOR_MODULES(rsa_reset, "8250_base");
 
 #ifdef CONFIG_SERIAL_8250_DEPRECATED_OPTIONS
 #ifndef MODULE
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: 37816488247ddddbc3de113c78c83572274b1e2e
change-id: 20250708-export_modules-12908fa41006

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

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

[David Hildenbrand]

On 08.08.25 15:28, 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.

I'm wondering if we could revisit that idea later, and have a config 
option that enables that. The use cases so far were mostly around 
testing IIRC, where people already run their own debug kernel or sth. 
like that.

-- 
Cheers,

David / dhildenb

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

[Vlastimil Babka]

On 8/8/25 4:17 PM, David Hildenbrand wrote:
> On 08.08.25 15:28, 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.
> 
> I'm wondering if we could revisit that idea later, and have a config
> option that enables that. The use cases so far were mostly around
> testing IIRC, where people already run their own debug kernel or sth.
> like that.

I don't know. It made sense to do this in-tree restriction when it
looked like it could be done unconditionally. But if it would need to be
opt-in config, I think there's little gain. As noted in the lwn
coverage, the metadata can be easily faked anyway. AFAIK the only
serious module loading restriction is then the module signing, so this
would be just a mostly pointless config option?

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

[Christian Brauner]

On Fri, 08 Aug 2025 15:28:47 +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 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.
> 
> [...]

Ok, so last I remember we said that this is going upstream rather sooner
than later before we keep piling on users. If that's still the case I'll
take it via vfs.fixes unless I hear objections.

---

Applied to the vfs.fixes branch of the vfs/vfs.git tree.
Patches in the vfs.fixes branch should appear in linux-next soon.

Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.

It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.

Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs.fixes

[1/1] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR_MODULES
      https://git.kernel.org/vfs/vfs/c/6d3c3ca4c77e

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

[Daniel Gomez]

On 11/08/2025 07.18, Christian Brauner wrote:
> On Fri, 08 Aug 2025 15:28:47 +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 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.
>>
>> [...]
> 
> Ok, so last I remember we said that this is going upstream rather sooner
> than later before we keep piling on users. If that's still the case I'll
> take it via vfs.fixes unless I hear objections.

This used to go through Masahiro's kbuild tree. However, since he is not
available anymore [1] I think it makes sense that this goes through the modules
tree. The only reason we waited until rc1 was released was because of Greg's
advise [2]. Let me know if that makes sense to you and if so, I'll merge this
ASAP.

Link: https://lore.kernel.org/all/CAK7LNAQW8b_HEQhWBzaQSPy=qDmKkqz6URtpJ+BYG8eq-sWRwA@mail.gmail.com/ [1]
Link: https://lore.kernel.org/all/2025072219-dollhouse-margarita-de67@gregkh/ [2]

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

[Christian Brauner]

On Tue, Aug 12, 2025 at 09:54:43AM +0200, Daniel Gomez wrote:
> On 11/08/2025 07.18, Christian Brauner wrote:
> > On Fri, 08 Aug 2025 15:28:47 +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 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.
> >>
> >> [...]
> > 
> > Ok, so last I remember we said that this is going upstream rather sooner
> > than later before we keep piling on users. If that's still the case I'll
> > take it via vfs.fixes unless I hear objections.
> 
> This used to go through Masahiro's kbuild tree. However, since he is not
> available anymore [1] I think it makes sense that this goes through the modules
> tree. The only reason we waited until rc1 was released was because of Greg's
> advise [2]. Let me know if that makes sense to you and if so, I'll merge this
> ASAP.

At this point it would mean messing up all of vfs.fixes to drop it from
there. So I'd just leave it in there and send it to Linus. Next time
I know where it'll end up.

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

[Daniel Gomez]

On 15/08/2025 07.25, Christian Brauner wrote:
> On Tue, Aug 12, 2025 at 09:54:43AM +0200, Daniel Gomez wrote:
>> On 11/08/2025 07.18, Christian Brauner wrote:j
>>> On Fri, 08 Aug 2025 15:28:47 +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 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.
>>>>
>>>> [...]
>>>
>>> Ok, so last I remember we said that this is going upstream rather sooner
>>> than later before we keep piling on users. If that's still the case I'll
>>> take it via vfs.fixes unless I hear objections.
>>
>> This used to go through Masahiro's kbuild tree. However, since he is not
>> available anymore [1] I think it makes sense that this goes through the modules
>> tree. The only reason we waited until rc1 was released was because of Greg's
>> advise [2]. Let me know if that makes sense to you and if so, I'll merge this
>> ASAP.
> 
> At this point it would mean messing up all of vfs.fixes to drop it from
> there. So I'd just leave it in there and send it to Linus.

Got it. I was waiting for confirmation before taking it into the modules tree,
and I agree that at this point it makes sense to keep it in vfs.fixes.

> Next time I know where it'll end up.

Can you clarify what you mean by this?

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

[Christian Brauner]

On Fri, Aug 15, 2025 at 05:39:54PM +0200, Daniel Gomez wrote:
> 
> 
> On 15/08/2025 07.25, Christian Brauner wrote:
> > On Tue, Aug 12, 2025 at 09:54:43AM +0200, Daniel Gomez wrote:
> >> On 11/08/2025 07.18, Christian Brauner wrote:j
> >>> On Fri, 08 Aug 2025 15:28:47 +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 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.
> >>>>
> >>>> [...]
> >>>
> >>> Ok, so last I remember we said that this is going upstream rather sooner
> >>> than later before we keep piling on users. If that's still the case I'll
> >>> take it via vfs.fixes unless I hear objections.
> >>
> >> This used to go through Masahiro's kbuild tree. However, since he is not
> >> available anymore [1] I think it makes sense that this goes through the modules
> >> tree. The only reason we waited until rc1 was released was because of Greg's
> >> advise [2]. Let me know if that makes sense to you and if so, I'll merge this
> >> ASAP.
> > 
> > At this point it would mean messing up all of vfs.fixes to drop it from
> > there. So I'd just leave it in there and send it to Linus.
> 
> Got it. I was waiting for confirmation before taking it into the modules tree,
> and I agree that at this point it makes sense to keep it in vfs.fixes.
> 
> > Next time I know where it'll end up.
> 
> Can you clarify what you mean by this?

Next time I know that you are responsible for taking such patches. :)