linux-kernel - Re: [PATCH] crypto: talitos - Remove GFP

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]

Date:   Mon, 9 Jan 2023 07:18:27 +0000
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Herbert Xu <herbert@...dor.apana.org.au>,
        Christoph Hellwig <hch@...radead.org>
CC:     Catalin Marinas <catalin.marinas@....com>,
        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>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: [PATCH] crypto: talitos - Remove GFP_DMA and add DMA alignment
 padding



Le 30/12/2022 à 08:31, Herbert Xu a écrit :
> GFP_DMA does not guarantee that the returned memory is aligned
> for DMA.  It should be removed where it is superfluous.

Doesn't GFP_DMA guarantees that the provided memory is addressable for 
DMA ? Or do we assume that all memory returned by kmalloc can be used 
for DMA ?

> 
> However, kmalloc may start returning DMA-unaligned memory in future
> so fix this by adding the alignment by hand.

kmalloc() already returns not DMA aligned memory, why does it becomes a 
problem now ?
Ok, that may be suboptimal, but is that a problem at all ?

By the way, I'm not sure I understand the solution, what's the added 
value of aligning allocation length to the cache alignment ?

> 
> Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>
> 
> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
> index 71db6450b6aa..d62ec68e3183 100644
> --- a/drivers/crypto/talitos.c
> +++ b/drivers/crypto/talitos.c
> @@ -1393,7 +1393,7 @@ static struct talitos_edesc *talitos_edesc_alloc(struct device *dev,
>   		alloc_len += sizeof(struct talitos_desc);
>   	alloc_len += ivsize;
>   
> -	edesc = kmalloc(alloc_len, GFP_DMA | flags);
> +	edesc = kmalloc(ALIGN(alloc_len, dma_get_cache_alignment()), flags);
>   	if (!edesc)
>   		return ERR_PTR(-ENOMEM);
>   	if (ivsize) {