On Wed, 13 Apr 2022 at 10:47, Catalin Marinas <catalin.marinas@xxxxxxx> wrote: .. > > Let's go back to restating the crypto code alignment requirements, as I > understand them (please correct): > > 1. Bus master accesses (DMA, CPUs that can't do efficient unaligned > accesses). That's what cra_alignmask is for. If there's a driver that > relies on an implicit kmalloc() alignment higher than cra_alignmask, > it is already broken on x86 and a few other architectures that don't > define ARCH_DMA_MINALIGN. But it won't be any worse with this series > since it only brings the arm64 kmalloc() alignment down from 128 to > 64. > > 2. Non-coherent DMA and cache invalidation. With my series, kmalloc'ed > buffers are DMA-safe for the CPU/SoC the kernel is running on. > > 3. DMA into buffers embedded in TFM structures. Since the offset of > those buffers is decided at compile-time, we need a > CRYPTO_MINALIGN_ATTR that covers both bus master alignment > requirements and the highest cache line size (CWG) for a non-coherent > DMA SoC. Ard's series would simplify the latter but, before then, > CRYPTO_MINALIGN needs to stay as the larger ARCH_DMA_MINALIGN. > > With my series, there is no change to the value of CRYPTO_MINALIGN for > arm64 or any other architecture, so point 3 is unaffected. The series > does change the kmalloc() alignment and that may be smaller than > CRYPTO_MINALIGN but neither of points 1 or 2 above are affected since > (a) we still have a sufficiently large ARCH_KMALLOC_MINALIGN of 64 and > (b) the kmalloc'ed buffers are safe for non-coherent DMA. > > Herbert, Ard, if I missed anything please let me know but based on my > understanding, this series is safe for the crypto code. > Agreed.
