linux-kernel - Re: [PATCH] spi: Ensure memory used for spi_write_then

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: <8bf5fb34-a554-4ab3-b774-470c08971447@sirena.org.uk>
Date: Thu, 27 Mar 2025 15:03:40 +0000
From: Mark Brown <broonie@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Petr Tesarik <ptesarik@...e.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	linux-kernel@...r.kernel.org, linux-spi@...r.kernel.org
Subject: Re: [PATCH] spi: Ensure memory used for spi_write_then_read() is DMA
 safe

On Wed, Mar 26, 2025 at 10:45:57PM +0100, Arnd Bergmann wrote:
> On Wed, Mar 26, 2025, at 17:20, Mark Brown wrote:
> > On Fri, Mar 21, 2025 at 08:42:12PM +0100, Arnd Bergmann wrote:

> >> Using dma_alloc_noncoherent() should make the implementation
> >> much nicer than GFP_DMA in the past, so we could add a bus
> >> specific helper for SPI that checks if the controller actually
> >> wants to do DMA and whether the buffer is problematic at all,
> >> and then decides to either allocate a bounce buffer and
> >> fill the sg table with the correct DMA address, map the
> >> existing buffer, or pass it without mapping depending on
> >> what the device needs.

> > That query feels a lot like spi_optimize_message().  Which should
> > possibly then just do the bouncing if it's needed.

> Would that require attaching the temporary buffer to the message
> or could that be a permanent bounce buffer?

We probably want to be able to do both - have a permanent buffer for
normal operation, and allocate a separate one when
spi_optimize_message() is explicitly called by the client code since the
idea is with the explicit calls is to be able to have the message baked
for a long time and you might have multiple messages ready.

> The advantage of using a permanent buffer is that it
> avoids both the kmalloc and the iommu mapping in the fast
> path and only needs to do the dma_sync_single_()
> for cache management, which should be faster for small
> transfers.

> The downside would be a higher memory usage and the
> need for a mutex.

Yes, the memory consumption is a potential issue.  We only tend to have
small numbers of SPI controllers though so if it's a page or two per
controller it's not too bad.  We could potentially make the buffer
discardable and allocate it on demand and release it under memory
pressure but that feels like a worry about when it's an issue kind of
thing.

For cases where we could use the source buffer directly we also have to
work out when it saves more overhead to use the existing mapping vs
doing a new mapping that skips a copy.

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