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 023F0C433F5 for ; Sun, 17 Apr 2022 08:43:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 908456B0072; Sun, 17 Apr 2022 04:43:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B88B6B0073; Sun, 17 Apr 2022 04:43:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 77FF56B0074; Sun, 17 Apr 2022 04:43:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 64DBA6B0072 for ; Sun, 17 Apr 2022 04:43:47 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 2977A2152E for ; Sun, 17 Apr 2022 08:43:47 +0000 (UTC) X-FDA: 79365732894.17.10CBE22 Received: from fornost.hmeau.com (helcar.hmeau.com [216.24.177.18]) by imf05.hostedemail.com (Postfix) with ESMTP id 646F3100005 for ; Sun, 17 Apr 2022 08:43:46 +0000 (UTC) Received: from gwarestrin.arnor.me.apana.org.au ([192.168.103.7]) by fornost.hmeau.com with smtp (Exim 4.94.2 #2 (Debian)) id 1ng0VJ-003jWG-6P; Sun, 17 Apr 2022 18:43:34 +1000 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Sun, 17 Apr 2022 16:43:33 +0800 Date: Sun, 17 Apr 2022 16:43:33 +0800 From: Herbert Xu To: Catalin Marinas Cc: Ard Biesheuvel , Will Deacon , Marc Zyngier , Arnd Bergmann , Greg Kroah-Hartman , Andrew Morton , Linus Torvalds , Linux Memory Management List , Linux ARM , Linux Kernel Mailing List , "David S. Miller" Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of herbert@gondor.apana.org.au designates 216.24.177.18 as permitted sender) smtp.mailfrom=herbert@gondor.apana.org.au; dmarc=none X-Stat-Signature: 4k73fajkt95q4nipjuxejtjye34zx1qg X-Rspamd-Queue-Id: 646F3100005 X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1650185026-886953 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 Sun, Apr 17, 2022 at 09:38:40AM +0100, Catalin Marinas wrote: > > I don't think we need to do anything here. A structure like: > > struct x { > char y; > char z[] CRYPTO_MINALIGN_ATTR; > }; > > is already of size 128. Without CRYPTO_MINALIGN_ATTR, its size would be > 1 but otherwise the whole structure inherits the alignment of its > member and this translates into an aligned size. No we should not lie to the compiler, we have code elsewhere that uses the alignment to compute the amount of extra padding needed to create greater padding. If CRYPTO_MINALIGN is misleading then that calculation will fall apart. So keep CRYPTO_MINALIGN at whatever alignment you lower kmalloc to, and then add the padding you need to separate the Crypto API bits from the context. In fact, that is exactly what cra_alignmask is supposed to do. Sure we currently limit the maximum alignment to 64 bytes because of stack usage but we can certainly look into increasing it as that's what you're doing here anyway. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt