linux-kernel - Re: [PATCH v8 01/17] spi: add basic support for SPI offloading

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

Message-ID: <094f00bc-1001-425f-87ca-84646b68bd70@sirena.org.uk>
Date: Tue, 11 Feb 2025 18:53:17 +0000
From: Mark Brown <broonie@...nel.org>
To: Uwe Kleine-König <ukleinek@...nel.org>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>,
	David Lechner <dlechner@...libre.com>,
	Jonathan Cameron <jic23@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Nuno Sá <nuno.sa@...log.com>,
	Michael Hennerich <Michael.Hennerich@...log.com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	David Jander <david@...tonic.nl>,
	Martin Sperl <kernel@...tin.sperl.org>, linux-spi@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-iio@...r.kernel.org,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH v8 01/17] spi: add basic support for SPI offloading

On Tue, Feb 11, 2025 at 07:45:30PM +0100, Uwe Kleine-König wrote:

> There was a similar discussion some time ago about the lpss pwm driver
> (https://lore.kernel.org/linux-pwm/Z09YJGifvpENYNPy@smile.fi.intel.com/).
> The arguments that you didn't accept back then already are similar to
> the ones that were brought forward here.
> The TL;DR; is: Adding MODULE_IMPORT_NS() to a header makes it easier for
> code to use the exported symbols. Yes, that includes abusers of the
> code.

> But if you mostly care about the regular users of an API/ABI, making
> things easy for those is the thing that matters. Agreed, if you think
> that module namespaces are primarily a line of defence against abusers,
> adding the import to the header weakens that defence (a bit). However a
> typical header includes function prototypes and macros. Those also make
> it easier for abusers. With your argumentation we better don't create
> headers at all?

> There are other benefits of module namespaces like reducing the set of
> globally available symbols which speeds up module loading or the
> ability to see in the module meta data that a namespace is used.

FWIW I fully endorse what Uwe is saying here, forcing every user of the
API to separately import the symbols seems more likely to create
busywork than to avoid problems.

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