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 A2564C433FE for ; Mon, 7 Nov 2022 09:38:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 17DE96B0071; Mon, 7 Nov 2022 04:38:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 12D896B0072; Mon, 7 Nov 2022 04:38:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01BC16B0073; Mon, 7 Nov 2022 04:38:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E5E286B0071 for ; Mon, 7 Nov 2022 04:38:22 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BBCA6A0D7D for ; Mon, 7 Nov 2022 09:38:22 +0000 (UTC) X-FDA: 80106145644.20.827ABD6 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf24.hostedemail.com (Postfix) with ESMTP id 0AC75180007 for ; Mon, 7 Nov 2022 09:38:21 +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 7A00DB80EE4; Mon, 7 Nov 2022 09:38:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A30A8C433D6; Mon, 7 Nov 2022 09:38:15 +0000 (UTC) Date: Mon, 7 Nov 2022 09:38:12 +0000 From: Catalin Marinas To: Herbert Xu Cc: Linus Torvalds , Arnd Bergmann , Christoph Hellwig , Greg Kroah-Hartman , Will Deacon , Marc Zyngier , Andrew Morton , Ard Biesheuvel , Isaac Manjarres , Saravana Kannan , Alasdair Kergon , Daniel Vetter , Joerg Roedel , Mark Brown , Mike Snitzer , "Rafael J. Wysocki" , Robin Murphy , linux-mm@kvack.org, iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 11/13] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN Message-ID: References: <20221106220143.2129263-1-catalin.marinas@arm.com> <20221106220143.2129263-12-catalin.marinas@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667813902; a=rsa-sha256; cv=none; b=AYmk9RnntdSE6C8BEEFSsLgux1arc4kYE7pbzT22cHG3/T4CbgNTT0wBUQFm/m7ZEK7X7Q 3y/zWgsoAJ+/4xzr7uzgtihF6cZecUC4/XsIef+WvYXTMyUnsp3k/0tkWH2BqdL3Zk6P5H odfP0+1Z8VFdq4ZQtK/21LolaW9lmQ4= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; spf=pass (imf24.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667813902; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PKqh3vQTdxlkqwUXu4+6JxeoMj6dADwEirHKj2pPEG4=; b=8P8T8xFEpJ9mt+uhYJQO6uzDKiclzqFPkWM0xlH4TeOTwxtp8fMeDBbhW2J+Mj4AIMbQM4 wvKjQOYzm5V9YcSCLapg+xmBtM5PQY93euzmC6ifvElEnc2Jyt2RIVGjGJN9LngwP5bhbF iYxhyQ5G1B1sD8TaWzEv75rl4GIampg= Authentication-Results: imf24.hostedemail.com; dkim=none; spf=pass (imf24.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 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: rspam12 X-Rspam-User: X-Stat-Signature: mjmwdjetp4e7anyfcu4xfdirwq766te1 X-Rspamd-Queue-Id: 0AC75180007 X-HE-Tag: 1667813901-186378 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 Mon, Nov 07, 2022 at 05:12:53PM +0800, Herbert Xu wrote: > On Mon, Nov 07, 2022 at 09:05:04AM +0000, Catalin Marinas wrote: > > Well, it does ensure that the __alignof__ and sizeof structures like > > crypto_alg and aead_request is still 128 after this change. A kmalloc() > > of a size multiple of 128 returns a 128-byte aligned object. So the aim > > is just to keep the current binary layout/alignment to 128 on arm64. In > > theory, no functional change. > > Changing CRYPTO_MINALIGN to 128 does not cause structures that are > smaller than 128 bytes to magically become larger than 128 bytes. For structures, it does (not arrays though): #define __aligned(x) __attribute__((__aligned__(x))) struct align_test1 { char c; char __aligned(128) data[]; }; struct align_test2 { char c; } __aligned(128); char aligned_array[4] __aligned(128); With the above, we have: sizeof(align_test1) == 128; __alignof__(align_test1) == 128; sizeof(align_test2) == 128; __alignof__(align_test2) == 128; sizeof(align_array) == 4; __alignof__(align_array) == 128; > If you're set on doing it this way then I can proceed with the > original patch-set to change the drivers. I've just been putting > it off because it seems that you guys weren't quite decided on > which way to go. Yes, reviving your patchset would help and that can be done independently of this series as long as the crypto code starts using dma_get_cache_alignment() and drops CRYPTO_MINALIGN_ATTR entirely. If at the point of creating the mask the code knows whether the device is coherent, it can even avoid any additional alignment (though still honouring the cra_alignmask that a device requires). So such reworking would be beneficial irrespective of this series. It seems that swiotlb bouncing is the preferred route and least intrusive but let's see the feedback on the other parts of the series. Thanks. -- Catalin