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 2D019C433EF for ; Wed, 6 Apr 2022 09:42:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 63D686B0072; Wed, 6 Apr 2022 05:42:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5ED5C6B0073; Wed, 6 Apr 2022 05:42:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4B4B96B0074; Wed, 6 Apr 2022 05:42:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 39BF16B0072 for ; Wed, 6 Apr 2022 05:42:23 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 08225210F3 for ; Wed, 6 Apr 2022 09:42:13 +0000 (UTC) X-FDA: 79325963346.09.5191E4E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf14.hostedemail.com (Postfix) with ESMTP id 4F767100039 for ; Wed, 6 Apr 2022 09:42:12 +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 2868161628 for ; Wed, 6 Apr 2022 09:42:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4B561C385B0 for ; Wed, 6 Apr 2022 09:42:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1649238130; bh=XzVxpBsHw3+lhhtvnfC+mj1Qwrhv5YqoiAyqzFtUD5c=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=EXCqvy/CnsUDmgpBZpBUyYOoMRigOSbEcWbSekemHlLuP/NeGZv3GnXF6zKtYN4T6 j2ilPqi6ypmKfsqtq07//UBu6eXYdNc3iDQn9U89kspijrH5KZdJr26UiJvKxRrc0T R40M+6Sn4X6XlGahw6Dzkuh+aDEupMBSUFIUtV3lzbWDeO/vfMlQJ0qeDhjbIcPQhp pnlEUPykGf5vxGnLRIf/1HSusoMyTAVQvMyZ1MG1E0dc17JFtKr2ImJejx7HKAYYoT THYRZnThLw3bRzIbgKrJL/lmmAxxyGcpnTjCapuNNQZcLnOpDDr5pkD/oRf6yJi65e 8u3T0W7mYlhBA== Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-d39f741ba0so2268065fac.13 for ; Wed, 06 Apr 2022 02:42:10 -0700 (PDT) X-Gm-Message-State: AOAM532V8LJ1vHCpWEChqG5IoT1FLxS7Uy+jnR6daojg4Axyq3I+xEN2 zBs+h2Id156/9/Qo6Svbl4jpDIqZBE2gGjRCfTs= X-Google-Smtp-Source: ABdhPJwwHH5A0PBmv1nZ8cSGrgFifDCeI9KaFOyeonSom2CtrOcrp6GXsNRKDdTSY+arKNjYbJZc0uwe9QynX2Cqj+M= X-Received: by 2002:a05:6870:b027:b0:de:7fcd:fabf with SMTP id y39-20020a056870b02700b000de7fcdfabfmr3489495oae.126.1649238129370; Wed, 06 Apr 2022 02:42:09 -0700 (PDT) MIME-Version: 1.0 References: <20220405135758.774016-1-catalin.marinas@arm.com> <20220405135758.774016-8-catalin.marinas@arm.com> In-Reply-To: From: Ard Biesheuvel Date: Wed, 6 Apr 2022 11:41:58 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN To: Catalin Marinas 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" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 4F767100039 X-Stat-Signature: 1go8hn4o8rfp5hr7qr5rxzuuz1yeu6jd X-Rspam-User: Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="EXCqvy/C"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf14.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org X-HE-Tag: 1649238132-422900 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, 6 Apr 2022 at 10:49, Catalin Marinas wrote: > > 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/ > I wasn't cc'ed on that :-) > 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. > No, not currently. But what I started looking into today is avoiding the need to impose DMA alignment on every single data structure allocated by the crypto API, even if it is never used for DMA or touched by a device. That seems rather wasteful as well.