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 0AE48C433F5 for ; Fri, 15 Apr 2022 12:19:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 13B276B0071; Fri, 15 Apr 2022 08:19:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0EAE66B0073; Fri, 15 Apr 2022 08:19:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF59B6B0074; Fri, 15 Apr 2022 08:19:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id DCE9B6B0071 for ; Fri, 15 Apr 2022 08:19:01 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id AA52162EF1 for ; Fri, 15 Apr 2022 12:19:01 +0000 (UTC) X-FDA: 79359017682.07.11D9F3B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id 1CADA40006 for ; Fri, 15 Apr 2022 12:19:00 +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 0E02E6168F; Fri, 15 Apr 2022 12:19:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 15709C385A6; Fri, 15 Apr 2022 12:18:56 +0000 (UTC) Date: Fri, 15 Apr 2022 13:18:53 +0100 From: Catalin Marinas To: Ard Biesheuvel Cc: Herbert Xu , 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: X-Rspam-User: X-Rspamd-Queue-Id: 1CADA40006 X-Stat-Signature: hobasibgux155mh8nipb3oycf4u5gjpo Authentication-Results: imf12.hostedemail.com; dkim=none; spf=pass (imf12.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) X-Rspamd-Server: rspam01 X-HE-Tag: 1650025140-467830 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 Fri, Apr 15, 2022 at 10:05:21AM +0200, Ard Biesheuvel wrote: > On Fri, 15 Apr 2022 at 09:52, Herbert Xu wrote: > > On Fri, Apr 15, 2022 at 09:49:12AM +0200, Ard Biesheuvel wrote: > > > I'm not sure I understand what would go wrong if that assumption no > > > longer holds. > > > > It's very simple, we don't do anything to the pointer returned > > by kmalloc before returning it as a tfm or other object with > > an alignment of CRYPTO_MINALIGN. IOW if kmalloc starts returning > > pointers that are not aligned to CRYPTO_MINALIGN then we'd be > > lying to the compiler. > > I guess that should be fixable. GIven that this is about padding > rather than alignment, we could do something like > > struct crypto_request { > union { > struct { > ... fields ... > }; > u8 __padding[ARCH_DMA_MINALIGN]; > }; > void __ctx[] __align(CRYPTO_MINALIGN); > }; > > And then hopefully, we can get rid of the padding once we fix drivers > doing non-cache coherent inbound DMA into those structures. But if we keep CRYPTO_MINALIGN as 128, don't we get the padding automatically? struct crypto_request { ... void *__ctx[] CRYPTO_MINALIGN_ATTR; }; __alignof__(struct crypto_request) == 128; sizeof(struct crypto_request) == N * 128 The same alignment and size is true for a structure like: struct crypto_alg { ... } CRYPTO_MINALIGN_ATTR; Any kmalloc() of sizeof(the above structures) will return a pointer aligned to 128, irrespective of what ARCH_KMALLOC_MINALIGN is. The problem is if you have a structure without any alignment attribute (just ABI default), making its sizeof() smaller than ARCH_DMA_MINALIGN. In this case kmalloc() could return a pointer aligned to something smaller. Is this the case in the crypto code today? I can see it uses the right alignment annotations already, no need for kmalloc() hacks. -- Catalin