linux-kernel - Re: [PATCH v4 2/7] nvmem: qcom-spmi-sdam: Migrate to devm_spmi_subdevice_alloc_and

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: <lq4rgzue6uah67nc7lob7eexsquk7qhr22wr4xwymzrvvopgc4@mkzyvadgd3qs>
Date: Fri, 19 Sep 2025 18:18:14 +0200
From: Uwe Kleine-König <u.kleine-koenig@...libre.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: David Lechner <dlechner@...libre.com>, 
	Andy Shevchenko <andriy.shevchenko@...el.com>, Andy Shevchenko <andy.shevchenko@...il.com>, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, sboyd@...nel.org, jic23@...nel.org, nuno.sa@...log.com, 
	andy@...nel.org, arnd@...db.de, srini@...nel.org, vkoul@...nel.org, 
	kishon@...nel.org, sre@...nel.org, krzysztof.kozlowski@...aro.org, 
	linux-arm-msm@...r.kernel.org, linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-phy@...ts.infradead.org, linux-pm@...r.kernel.org, kernel@...labora.com, 
	wenst@...omium.org, casey.connolly@...aro.org, 
	Konrad Dybcio <konrad.dybcio@....qualcomm.com>, Neil Armstrong <neil.armstrong@...aro.org>
Subject: Re: [PATCH v4 2/7] nvmem: qcom-spmi-sdam: Migrate to
 devm_spmi_subdevice_alloc_and_add()

Hello Greg,

On Fri, Sep 19, 2025 at 05:13:35PM +0200, Greg KH wrote:
> On Fri, Sep 19, 2025 at 10:05:28AM -0500, David Lechner wrote:
> > On 9/19/25 8:59 AM, Greg KH wrote:
> > > On Thu, Sep 18, 2025 at 10:00:29PM +0300, Andy Shevchenko wrote:
> > >> I,o.w. I principally disagree on putting MODULE_IMPORT_NS() into the header
> > >> file.
> > > 
> > > Yes, please never do that, it defeats the purpose of module namespaces
> > > completly.  If you don't want to have module namespaces, don't use them
> > > for your subsytem.  Don't use them and then make them moot by putting
> > > MODULE_IMPORT_NS() in the .h file for the symbols as that's pointless.
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > 
> > 
> > Could someone suggest some additional explanation to add to
> > Documentation/core-api/symbol-namespaces.rst to explain the
> > reasoning behind this?
> > 
> > Right now, the only part of that document that say _why_ we have
> > module namespces says:
> > 
> > 	That is useful for documentation purposes (think of the
> > 	SUBSYSTEM_DEBUG namespace) as well as for limiting the
> > 	availability of a set of symbols for use in other parts
> > 	of the kernel.
> > 
> > So I don't see the connection between this explanation and and:
> > 
> > 	[Putting MODULE_IMPORT_NS() into the header] defeats
> > 	the purpose of module namespaces completely.
> > 
> > I am guilty of putting it in a header, so if I need to fix that
> > I would like to actually understand why first. Andy has mentioned
> > something about potential abuses, but without any example, I haven't
> > been able to understand what this would actually actually look like.
> > Or maybe there is some other reason that Greg is thinking of that
> > hasn't been mentioned yet?
> 
> Let me turn it around, _why_ would you want your exports in a namespace
> at all if you just are putting a MODULE_IMPORT_NS() in the .h file at
> the same time?  What is this giving you at all compared to just a normal
> MODULE_EXPORT() marking for your exports?
> 
> I know what it gives me when I don't put it in a .h file, but I think
> that might be different from what you are thinking here :)

For me (who still today thinks it's elegant to put the MODULE_IMPORT_NS
in a header next to the declarations of the symbols in that namespace)
it's the documentation thing quoted above (e.g. modinfo lists the used
namespaces) and to unclutter the global namespace.

The latter was essentially the motivation to introduce symbol
namespaces, see the cover letter from back then[1].

Personally I don't see the relevance of making it harder for abusers.

A non-GPL module should be stopped by the symbol being exported using
EXPORT_SYMBOL_GPL() with or without namespaces. And for a binary
distribution of a module the need to add the MODULE_IMPORT_NS statement
in the source code is a quite low barrier for the evil binary module
distributor that IMHO doesn't justify to burden all regular users of a
namespace to have to do two things (#include + MODULE_IMPORT_NS) instead
of only one (include which implies the MODULE_IMPORT_NS) to make use of
said namespace.

And for GPL code: Who is actually an abuser of say devm_pwm_get()?
In my eyes any module should be free to use that function. And if it's
not sensible to do so, I would expect this to be discovered even without
the needed MODULE_IMPORT_NS("PWM") in the code. And if it's not
discovered that's fine for me, too. For me that's the spirit of Open
Source: If someone finds devm_pwm_get() useful, let them use it. Please
even tell me if you use it in a way I didn't expect, I'm glad to hear
about it.

I'm probably missing something.

Best regards
Uwe

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)