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
| ||
|
Message-ID: <Y0b9SYI7v94ig5v8@google.com> Date: Wed, 12 Oct 2022 10:45:45 -0700 From: Isaac Manjarres <isaacmanjarres@...gle.com> To: Catalin Marinas <catalin.marinas@....com> Cc: Herbert Xu <herbert@...dor.apana.org.au>, Ard Biesheuvel <ardb@...nel.org>, Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>, Arnd Bergmann <arnd@...db.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Andrew Morton <akpm@...ux-foundation.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Linux Memory Management List <linux-mm@...ck.org>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>, Saravana Kannan <saravanak@...gle.com>, kernel-team@...roid.com Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN On Fri, Sep 30, 2022 at 07:32:50PM +0100, Catalin Marinas wrote: > I started refreshing the series but I got stuck on having to do bouncing > for small buffers even if when they go through the iommu (and I don't > have the set up to test it yet). For devices that go through the IOMMU, are you planning on adding similar logic as you did in the direct-DMA path to bounce the buffer prior to calling into whatever DMA ops are registered for the device? Also, there are devices with ARM64 CPUs that disable SWIOTLB usage because none of the peripherals that they engage in DMA with need bounce buffering, and also to reclaim the default 64 MB of memory that SWIOTLB uses. With this approach, SWIOTLB usage will become mandatory if those devices need to perform non-coherent DMA transactions that may not necessarily be DMA aligned (e.g. small buffers), correct? If so, would there be concerns that the memory savings we get back from reducing the memory footprint of kmalloc might be defeated by how much memory is needed for bounce buffering? I understand that we can use the "swiotlb=num_slabs" command line parameter to minimize the amount of memory allocated for bounce buffering. If this is the only way to minimize this impact, how much memory would you recommend to allocate for bounce buffering on a system that will only use bounce buffers for non-DMA-aligned buffers? Thanks, Isaac
Powered by blists - more mailing lists