From: Catalin Marinas <catalin.marinas@arm.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Ard Biesheuvel <ardb@kernel.org>, Will Deacon <will@kernel.org>,
Marc Zyngier <maz@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [v2 PATCH 2/9] crypto: api - Add crypto_tfm_ctx_dma
Date: Fri, 25 Nov 2022 11:31:56 +0000 [thread overview]
Message-ID: <Y4CnrGmT5o7zcLJr@arm.com> (raw)
In-Reply-To: <E1oyQRz-000djH-3a@formenos.hmeau.com>
Hi Herbert,
Thanks for putting this together. I'll try to go through the series but
my crypto knowledge is fairly limited.
On Fri, Nov 25, 2022 at 12:36:31PM +0800, Herbert Xu wrote:
> diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
> index f50c5d1725da..4c99eb66e654 100644
> --- a/include/crypto/algapi.h
> +++ b/include/crypto/algapi.h
> @@ -7,6 +7,7 @@
> #ifndef _CRYPTO_ALGAPI_H
> #define _CRYPTO_ALGAPI_H
>
> +#include <asm/cache.h>
> #include <linux/align.h>
> #include <linux/crypto.h>
> #include <linux/kconfig.h>
> @@ -25,6 +26,14 @@
> #define MAX_CIPHER_BLOCKSIZE 16
> #define MAX_CIPHER_ALIGNMASK 15
>
> +#ifdef ARCH_DMA_MINALIGN
> +#define CRYPTO_DMA_ALIGN ARCH_DMA_MINALIGN
> +#else
> +#define CRYPTO_DMA_ALIGN CRYPTO_MINALIGN
> +#endif
> +
> +#define CRYPTO_DMA_PADDING ((CRYPTO_DMA_ALIGN - 1) & ~(CRYPTO_MINALIGN - 1))
Is the CRYPTO_DMA_PADDING used anywhere? I couldn't find it in this
series and I'd rather drop it, together with CRYPTO_DMA_ALIGN (see
below).
> +
> struct crypto_aead;
> struct crypto_instance;
> struct module;
> @@ -189,10 +198,38 @@ static inline void crypto_xor_cpy(u8 *dst, const u8 *src1, const u8 *src2,
> }
> }
>
> +static inline void *crypto_tfm_ctx(struct crypto_tfm *tfm)
> +{
> + return tfm->__crt_ctx;
> +}
> +
> +static inline void *crypto_tfm_ctx_align(struct crypto_tfm *tfm,
> + unsigned int align)
> +{
> + if (align <= crypto_tfm_ctx_alignment())
> + align = 1;
> +
> + return PTR_ALIGN(crypto_tfm_ctx(tfm), align);
> +}
> +
> static inline void *crypto_tfm_ctx_aligned(struct crypto_tfm *tfm)
> {
> - return PTR_ALIGN(crypto_tfm_ctx(tfm),
> - crypto_tfm_alg_alignmask(tfm) + 1);
> + return crypto_tfm_ctx_align(tfm, crypto_tfm_alg_alignmask(tfm) + 1);
>+}
I had an attempt to make crypto_tfm_alg_alignmask() the larger of the
cra_alignmask and ARCH_DMA_MINALIGN but for some reason the kernel
started to panic, so I gave up.
> +
> +static inline unsigned int crypto_dma_align(void)
> +{
> + return CRYPTO_DMA_ALIGN;
> +}
We have a generic dma_get_cache_alignment() function which currently is
either 1 or ARCH_DMA_MINALIGN, if the latter is defined. My plan is to
make eventually make this dynamic based on the actual cache line size
(on most arm64 systems it would be 64 rather than 128). So could you use
this instead of defining a CRYPTO_DMA_ALIGN? The only difference would
be that dma_get_cache_alignment() returns 1 rather than
ARCH_KMALLOC_MINALIGN if ARCH_DMA_MINALIGN is not defined, but I don't
think that's an issue.
> +
> +static inline unsigned int crypto_dma_padding(void)
> +{
> + return (crypto_dma_align() - 1) & ~(crypto_tfm_ctx_alignment() - 1);
> +}
> +
> +static inline void *crypto_tfm_ctx_dma(struct crypto_tfm *tfm)
> +{
> + return crypto_tfm_ctx_align(tfm, crypto_dma_align());
> }
These would need to cope with crypto_dma_align() < ARCH_KMALLOC_MINALIGN.
I think that's fine, the padding will be 0 if crypto_dma_align() is 1.
--
Catalin
next prev parent reply other threads:[~2022-11-25 11:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-25 4:35 [v2 PATCH 0/9] crypto: Add helpers for allocating with DMA alignment Herbert Xu
2022-11-25 4:36 ` [v2 PATCH 1/9] crypto: Prepare to move crypto_tfm_ctx Herbert Xu
2022-11-25 4:36 ` [v2 PATCH 2/9] crypto: api - Add crypto_tfm_ctx_dma Herbert Xu
2022-11-25 11:31 ` Catalin Marinas [this message]
2022-11-28 3:59 ` Herbert Xu
2022-11-25 4:36 ` [v2 PATCH 3/9] crypto: aead - Add ctx helpers with DMA alignment Herbert Xu
2022-11-25 12:24 ` Catalin Marinas
2022-11-28 4:06 ` Herbert Xu
2022-11-25 4:36 ` [v2 PATCH 4/9] crypto: hash " Herbert Xu
2022-11-25 4:36 ` [v2 PATCH 5/9] crypto: skcipher " Herbert Xu
2022-11-25 4:36 ` [v2 PATCH 6/9] crypto: api - Increase MAX_ALGAPI_ALIGNMASK to 127 Herbert Xu
2022-11-25 4:36 ` [v2 PATCH 7/9] crypto: akcipher - Add ctx helpers with DMA alignment Herbert Xu
2022-11-25 4:36 ` [v2 PATCH 8/9] crypto: kpp " Herbert Xu
2022-11-25 4:36 ` [v2 PATCH 9/9] crypto: caam - Set DMA alignment explicitly Herbert Xu
2022-11-25 12:17 ` [v2 PATCH 0/9] crypto: Add helpers for allocating with DMA alignment Ard Biesheuvel
2022-11-28 4:05 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y4CnrGmT5o7zcLJr@arm.com \
--to=catalin.marinas@arm.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maz@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).