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

Message-ID: <9ac953ec-fba3-41a7-8e5d-b867abc1566f@sirena.org.uk>
Date: Thu, 20 Mar 2025 15:34:42 +0000
From: Mark Brown <broonie@...nel.org>
To: Petr Tesarik <ptesarik@...e.com>
Cc: Arnd Bergmann <arnd@...db.de>, Grant Likely <grant.likely@...retlab.ca>,
	linux-kernel@...r.kernel.org, linux-spi@...r.kernel.org,
	Robin Murphy <robin.murphy@....com>
Subject: Re: [PATCH] spi: Ensure memory used for spi_write_then_read() is DMA
 safe

On Thu, Mar 20, 2025 at 03:35:36PM +0100, Petr Tesarik wrote:

> CC'ing Robin Murphy, because there seem to be some doubts about DMA API
> efficiency.

Or possibly just documentation, the number of memory types we have to
deal with and disjoint interfaces makes all this stuff pretty miserable.

> > > The whole goal there is to try to avoid triggering another copy to do
> > > the DMA so just reverting rather than replacing with some other
> > > construct that achieves the same goal doesn't seem great.  I think
> > > possibly we should just not do the copy at all any more and trust the
> > > core to DTRT with any buffers that are passed in, I think we've got
> > > enough stuff in the core though I can't remember if it'll copy with
> > > things allocated on the stack well.  I'd need to page the status back
> > > in.  

> No, I'm afraid kernel stack addresses (and many other types of
> addresses) cannot be used for DMA:

> https://docs.kernel.org/core-api/dma-api-howto.html#what-memory-is-dma-able

Right, that's what I thought.  Part of what spi_write_then_read() is
doing is taking the edge off that particular sharp edge for users, on
the off chance that the controller wants to DMA.

> > From what I found, there are two scenarios that may depend on
> > GFP_DMA today:

> >  a) a performance optimization where allocating from GFP_DMA avoids
> >     the swiotlb bounce buffering. This would be the normal case on
> >     any 64-bit machine with more than 4GB of RAM and an SPI
> >     controller with a 32-bit DMA mask.

> I must be missing something. How is a memcpy() in spi_write_then_read()
> faster than a memcpy() by swiotlb?

spi_write_then_read() is just a convenience API, a good proportion of
users will be using spi_sync() directly.

> I still believe the SPI subsystem should not try to be clever. The
> DMA API already avoids unnecessary copying as much as possible.

It's not particularly trying to be clever here?

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