linux-kernel - Re: [PATCH 2/5] devres: export devres_node_init() and devres_node

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: <aYYXSPtndNSPZDH-@google.com>
Date: Fri, 6 Feb 2026 16:31:04 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Danilo Krummrich <dakr@...nel.org>, Matthew Maurer <mmaurer@...gle.com>, rafael@...nel.org, 
	ojeda@...nel.org, boqun.feng@...il.com, gary@...yguo.net, 
	bjorn3_gh@...tonmail.com, lossin@...nel.org, a.hindborg@...nel.org, 
	tmgross@...ch.edu, driver-core@...ts.linux.dev, 
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] devres: export devres_node_init() and devres_node_add()

On Fri, Feb 06, 2026 at 03:09:09PM +0000, Alice Ryhl wrote:
> On Fri, Feb 06, 2026 at 02:55:50PM +0100, Greg KH wrote:
> > On Fri, Feb 06, 2026 at 01:33:53PM +0000, Alice Ryhl wrote:
> > > On Fri, Feb 06, 2026 at 02:22:42PM +0100, Greg KH wrote:
> > > > On Fri, Feb 06, 2026 at 02:16:05PM +0100, Danilo Krummrich wrote:
> > > > > However, sprinkling "raw" EXPORT_SYMBOL_GPL() due to that is not great at all.
> > > > > Hence, we could do something like in [1] instead. I don't know if there are
> > > > > other options that may be better though.
> > > > > 
> > > > > [1] https://lore.kernel.org/all/DG7UR3WWZB4V.2MYMJJH1VDHH@kernel.org/
> > > > 
> > > > That's a start, but still messy.  There's no compiler options to prevent
> > > > this "lifting" of the code out of devres.rs?  If not, this is not going
> > > > to be the only problem that drivers run into like this in the future.
> > > 
> > > Because of how monomorphisation, as-is the code actually lives in the
> > > module to begin with.
> > 
> > Ok, but again, that is going to cause all sorts of "the symbol is
> > undefined" type of problems going forward as a developers just "assumes"
> > that the place where the symbol is exported will actually have the
> > symbol exported from it, not that this place will be copied inline into
> > somewhere else.
> > 
> > Think about the interaction between module symbol namespaces here.  This
> > isn't going to scale, and will trip people up and cause us to be forced
> > to export way more than we really want to (like this patch series shows,
> > I don't want to export any of these...)
> 
> Hmm. I don't know how to reconcile namespaces operating on symbols with
> monomorphisation.
> 
> We should probably think about what to do about ... :)

Matthew Maurer pointed out to me that behavior-wise exporting and
namespaces behave almost exactly the same as how Rust handles unstable
language features.

In the Rust standard library, all functions are marked with one of:

	#[unstable(feature = "feature_name_here")]
	#[stable]

when you use a #[stable] method, all is good. But if you use an unstable
method, then that's a compiler error unless you have

	#![feature(feature_name_here)]

at the crate root.

This seems equivalent to our situation here, if we consider:

* EXPORT_SYMBOL_GPL symbols are #[stable]
* un-exported symbols are #[unstable(feature = "core_kernel")]
* other namespaces are #[unstable(feature = "namespace_name_here")]

Of course the way this is enforced is through an entirely different
mechanism than symbol exports.

Alice