From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92818C433F5 for ; Wed, 6 Apr 2022 08:50:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2F5EE6B0073; Wed, 6 Apr 2022 04:50:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A5906B0074; Wed, 6 Apr 2022 04:50:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 194E46B0075; Wed, 6 Apr 2022 04:50:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 0CD116B0073 for ; Wed, 6 Apr 2022 04:50:01 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id DE3D5247E0 for ; Wed, 6 Apr 2022 08:49:50 +0000 (UTC) X-FDA: 79325831340.03.5BB5772 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf21.hostedemail.com (Postfix) with ESMTP id 488B81C0021 for ; Wed, 6 Apr 2022 08:49:50 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4C558613E2; Wed, 6 Apr 2022 08:49:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88C3EC385A3; Wed, 6 Apr 2022 08:49:46 +0000 (UTC) Date: Wed, 6 Apr 2022 09:49:42 +0100 From: Catalin Marinas To: Ard Biesheuvel Cc: Herbert Xu , Will Deacon , Marc Zyngier , Arnd Bergmann , Greg Kroah-Hartman , Andrew Morton , Linus Torvalds , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, "David S. Miller" Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN Message-ID: References: <20220405135758.774016-1-catalin.marinas@arm.com> <20220405135758.774016-8-catalin.marinas@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 488B81C0021 X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf21.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org X-Stat-Signature: 6usxg1wprqs9h13dgha61yibwk7fjkgj X-HE-Tag: 1649234990-601223 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Apr 06, 2022 at 08:53:33AM +0200, Ard Biesheuvel wrote: > On Wed, 6 Apr 2022 at 00:57, Herbert Xu wrote: > > On Tue, Apr 05, 2022 at 02:57:55PM +0100, Catalin Marinas wrote: > > > ARCH_DMA_MINALIGN represents the minimum (static) alignment for safe DMA > > > operations while ARCH_KMALLOC_MINALIGN is the minimum kmalloc() objects > > > alignment. > > > > > > Signed-off-by: Catalin Marinas > > > Cc: Herbert Xu > > > Cc: "David S. Miller" > > > --- > > > include/linux/crypto.h | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/include/linux/crypto.h b/include/linux/crypto.h > > > index 2324ab6f1846..654b9c355575 100644 > > > --- a/include/linux/crypto.h > > > +++ b/include/linux/crypto.h > > > @@ -167,7 +167,7 @@ > > > * maintenance for non-coherent DMA (cache invalidation in particular) does not > > > * affect data that may be accessed by the CPU concurrently. > > > */ > > > -#define CRYPTO_MINALIGN ARCH_KMALLOC_MINALIGN > > > +#define CRYPTO_MINALIGN ARCH_DMA_MINALIGN > > > > I think this should remain as ARCH_KMALLOC_MINALIGN with the > > comment above modified. The reason is that we assume memory > > returned by kmalloc is already aligned to this value. > > > > Ard, you added the comment regarding the DMA requirement, so > > does anything actually rely on this? If they do, they now need > > to do their own alignment. > > This patch looks incorrect to me, as ARCH_DMA_MINALIGN is not > #define'd on all architectures. It is after the first patch: https://lore.kernel.org/all/20220405135758.774016-2-catalin.marinas@arm.com/ The series makes both ARCH_*_MINALIGN available irrespective of what an arch defines. If one needs guaranteed static alignment for DMA, use the DMA macro. If the minimum kmalloc() alignment is needed (e.g. to store some flags in the lower pointer bits), use the KMALLOC macro. I grep'ed through drivers/ and I've seen both cases (e.g. drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c for the latter use-case). > But I am fine with the intent: ARCH_DMA_MINALIGN will be >= > ARCH_KMALLOC_MINALIGN, and so the compile time layout of structs will > take the worst cast minimum DMA alignment into account, whereas their > placement in memory when they allocated dynamically may be aligned to > ARCH_KMALLOC_MINALIGN only. Since the latter will be based on the > actual cache geometry, this should be fine. That's the idea. > Apart from the 'shash desc on stack' issue solved by the patch that > also introduced the above comment(660d2062190d), I've never looked > into the actual memory footprint of the crypto related data structures > resulting from this alignment, but it seems to me that /if/ this is > significant, we should be able to punt this to the drivers that > actually need this, rather than impose it for the whole system. (This > would involve over-allocating the context struct, and aligning up the > pointer in the various xxx_ctx() getters iff needed by the driver in > question) Since ARCH_KMALLOC_MINALIGN on arm64 prior to this series is 128, there is any change to the crypto code. -- Catalin