Re: [PATCH 0/2] crypto: fix RSA results corrupted by non-coherent DMA

[Stephane Debusne]

Hi Jeff,

On Fri, Oct 16, 2026 at 06:14:14PM -0400, Jeff Barnes wrote:
> Your patches move the synchronous-helper and RSASSA-PKCS1 buffers into
> separate allocations, while intentionally retaining src == dst.

Yes. The in-place request shape predates this series (the sync helper
has used it since it was introduced, rsassa_pkcs1_verify() since
8552cb04e083), and I understand in-place requests to be valid for
akcipher, so I kept the series limited to the placement of the buffer.
I agree that the two issues are independent.

One data point from the i.MX8M Mini (CAAM era 9, non-coherent, no IOMMU
in front of the CAAM): with dma-direct, both mappings of the shared SG
return the same address, so the double mapping has no visible effect
there. In-place requests on a buffer from its own kmalloc() gave no
wrong result out of 200 in my test module, and with this series
applied, rsa-caam passes signature verification. I have not run with
CONFIG_DMA_API_DEBUG, which should report the overlapping mappings even
without an IOMMU; I can do so if that helps.

> Would the preferred direction be:

I will leave the choice to Herbert and the CAAM maintainers. For what
it is worth, a narrowly bounded RFC (your option 1) seems the easiest
to review, and I can test it on the i.MX8M Mini as a regression check
on a non-coherent system without an IOMMU.

Thanks for the pointer to Changwei's series, which I had missed. It
fixes the same corruption from the driver side. I have now tested it
on the i.MX8M Mini: with it alone, the buffers built by the sync helper
and by rsassa_pkcs1_verify(), which are not cacheline-aligned, are
bounced, and rsa-caam gives correct results. I sent my Tested-by on his
thread. The two approaches are complementary: with my series those
buffers are aligned and need no bounce, while the driver change also
covers other callers.

Thanks,
Stephane