> -----Original Message----- > From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > Sent: Thursday, September 24, 2020 5:12 AM > To: Van Leeuwen, Pascal <pvanleeuwen@xxxxxxxxxx> > Cc: linux-crypto@xxxxxxxxxxxxxxx; antoine.tenart@xxxxxxxxxxx; davem@xxxxxxxxxxxxx; Ard Biesheuvel <ardb@xxxxxxxxxx> > Subject: Re: [PATCH] crypto: inside-secure - Fix corruption on not fully coherent systems > > <<< External Email >>> > On Fri, Sep 18, 2020 at 08:21:44AM +0000, Van Leeuwen, Pascal wrote: > > > > > Can this alignment exceed ARCH_DMA_MINALIGN? If not then the > > > macro CRYPTO_MINALIGN should cover it. > > > > I don't know. I'm not familiar with that macro and I have not been able to dig up any > > clear description on what it should convey. > > I'm pretty sure it is because that's the reason kmalloc uses it > as its minimum as otherwise memory returned by kmalloc may cross > cache-lines. > If that is indeed what kmalloc uses for alignment, good point ... I suppose if that is guaranteed, it is a possible alternative solution to at least the coherence problem I needed to solve. But, why use some fixed worst case value if you can be more smart about it? (That applies to kmalloc as well, by the way ... why does it use some fixed define for that and not the dynamically discovered system cache line size?) Also, there is some benefit to aligning these buffers for systems that ARE fully coherent and therefore do not (seem to) define ARCH_DMA_MINALIGN. Although that would also apply to any kmalloc'd buffers supplied externally ... > > In any case, aligning to the worst cache cacheline for a CPU architecture may mean > > you end up wasting a lot of space on a system with a much smaller cacheline. > > It won't waste any memory because kmalloc is already using it as > a minimum. > The fact that kmalloc uses it does _not_ rule out the fact that it wastes memory ... And as long as you use kmalloc for fairly large data structures, it shouldn't matter much. But here I need a couple of fairly small buffers. > Cheers, > -- > Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt Regards, Pascal van Leeuwen Silicon IP Architect Multi-Protocol Engines, Rambus Security Rambus ROTW Holding BV +31-73 6581953 Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by Rambus. Please be so kind to update your e-mail address book with my new e-mail address. ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. ** Rambus Inc.<http://www.rambus.com>
