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 05265C433F5 for ; Wed, 6 Apr 2022 06:54:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6ABE66B0072; Wed, 6 Apr 2022 02:53:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 65AF96B0073; Wed, 6 Apr 2022 02:53:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 521F16B0074; Wed, 6 Apr 2022 02:53:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0082.hostedemail.com [216.40.44.82]) by kanga.kvack.org (Postfix) with ESMTP id 405DA6B0072 for ; Wed, 6 Apr 2022 02:53:59 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E7C998249980 for ; Wed, 6 Apr 2022 06:53:48 +0000 (UTC) X-FDA: 79325538936.24.F297D62 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf10.hostedemail.com (Postfix) with ESMTP id 44FBFC001C for ; Wed, 6 Apr 2022 06:53:48 +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 ams.source.kernel.org (Postfix) with ESMTPS id 581CDB82109 for ; Wed, 6 Apr 2022 06:53:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06B92C385AC for ; Wed, 6 Apr 2022 06:53:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1649228026; bh=tO8JMyLzIZ8EITkhp2PubbOl10W7/jlZTi8jH9cyTLA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=k0dPNLOFXD0NO7pwwnpOcM17yCmaDTXu/JTYP0X6yByGl0JOQucrjAtJzkKILFDgt DSTQSo8yPhjvPvBmNbyel6rRrt4/15PnMN2lQziq+CZsz+70pBbIMzzgV+x68fasH+ 4kdp54NwrvPrw4kBJvX/ZZd5D/AHZ8ZYujG4Q50Rytum/nCOH6J4D19SSUqnLyq444 YfdmhdsqppJBjydZK5tzib2BZGfDrLMND8tWRVc9Us67lKdqeXFuCfY8+CV8AvO3Ll WevPFimEj1/yXJ0a5UbDE/hDXuJAFcXSo0VdeqeNdudgysy1K5L8cmk8egw2FN9s4x /UryyMD+J4sxA== Received: by mail-ot1-f48.google.com with SMTP id z9-20020a05683020c900b005b22bf41872so1120875otq.13 for ; Tue, 05 Apr 2022 23:53:45 -0700 (PDT) X-Gm-Message-State: AOAM530L4uvHhB1hBFY8JiyiQLbTkCwgskHzkdYNJJLsSut1ClPNw2Dq Z/F5T8EwdGu5YI+qFsqLN7ShUJ1C6i8SDgcmjGE= X-Google-Smtp-Source: ABdhPJwt+MqYoXIE9XnpjhA1n4uGXTgDOGNThyoHryIuaDZN64VMoEbM5En07e+MLJhoR+DsVsRXvaQFlGgRZfSRASs= X-Received: by 2002:a05:6830:1e9c:b0:5cd:8c15:5799 with SMTP id n28-20020a0568301e9c00b005cd8c155799mr2506585otr.265.1649228025072; Tue, 05 Apr 2022 23:53:45 -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 08:53:33 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN To: Herbert Xu Cc: Catalin Marinas , 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" Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=k0dPNLOF; spf=pass (imf10.hostedemail.com: domain of ardb@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: o59p6m48uo58iuthxtqcq9zg8s8a6kqq X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 44FBFC001C X-HE-Tag: 1649228028-398076 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 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. 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. 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) I'll put this on my list of things to look at.