linux-kernel - Re: [PATCH v2] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to EXPORT_SYMBOL_FOR

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] [day] [month] [year] [list]

Message-ID: <20250714-geliebt-neupositionierung-f69ca29c5e40@brauner>
Date: Mon, 14 Jul 2025 10:08:15 +0200
From: Christian Brauner <brauner@...nel.org>
To: Vlastimil Babka <vbabka@...e.cz>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Matthias Maennich <maennich@...gle.com>, 
	Jonathan Corbet <corbet@....net>, Luis Chamberlain <mcgrof@...nel.org>, 
	Petr Pavlu <petr.pavlu@...e.com>, Sami Tolvanen <samitolvanen@...gle.com>, 
	Daniel Gomez <da.gomez@...sung.com>, Masahiro Yamada <masahiroy@...nel.org>, 
	Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas.schier@...ux.dev>, 
	Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>, Christoph Hellwig <hch@...radead.org>, 
	Peter Zijlstra <peterz@...radead.org>, David Hildenbrand <david@...hat.com>, 
	Shivank Garg <shivankg@....com>, "Jiri Slaby (SUSE)" <jirislaby@...nel.org>, 
	Stephen Rothwell <sfr@...b.auug.org.au>, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-modules@...r.kernel.org, linux-kbuild@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v2] module: Rename EXPORT_SYMBOL_GPL_FOR_MODULES to
 EXPORT_SYMBOL_FOR_MODULES

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@...radead.org>
> Reviewed-by: Shivank Garg <shivankg@....com>
> Acked-by: Christian Brauner <brauner@...nel.org>
> Acked-by: David Hildenbrand <david@...hat.com>
> Signed-off-by: Vlastimil Babka <vbabka@...e.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@...nel.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/
> ---