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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 10DC2C433EF for ; Tue, 12 Apr 2022 09:34:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bHwuCTkD1VPNCxQ54QOm7mQ0GeQg/UdkelhZxAqccGM=; b=bLU1qJbgVXEfST kQaMqO11Xpoj5QYNiIKkgOAuhZkh9k+AqnLgFw5CbJQ5qnjMZdCKXDElkMASBcCtRnc7rESIZ8Fkr lJra92wufom3WIKcq/yFaaRhUg33r4LVSIq5e8awoZXuLLmtj96w0Y7Qwf1FQAgYlo5qCfgIJumfp yKBoJojJ1UfmyYVlg+PfAbC/ILQubhRI/5i/7Twu5J69uprgx65Mkh+tvj+nh+VsGg1ZCPVVLTpxO EOy1MfQuzNSCSJLFxKfYjdIyuJW+c/CM19HBooAF6pWg4L/Mk3qnhnK9NPC2VXKCh11DC8Fb1jNF5 PvQv2RaPOQ33DMnTXemQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1neCtZ-00CwdN-Gn; Tue, 12 Apr 2022 09:33:09 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1neCtV-00Cwc1-R4 for linux-arm-kernel@lists.infradead.org; Tue, 12 Apr 2022 09:33:07 +0000 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 E7C70617D8; Tue, 12 Apr 2022 09:33:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E77CC385A5; Tue, 12 Apr 2022 09:33:02 +0000 (UTC) Date: Tue, 12 Apr 2022 10:32:58 +0100 From: Catalin Marinas To: Herbert Xu Cc: Ard Biesheuvel , 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" Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220412_023305_987917_F214BD0F X-CRM114-Status: GOOD ( 27.64 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Apr 08, 2022 at 05:11:28PM +0800, Herbert Xu wrote: > On Fri, Apr 08, 2022 at 10:04:54AM +0100, Catalin Marinas wrote: > > My point is that if the crypto code kmallocs a size aligned to > > crypto_tfm_ctx_alignment() (and CRYPTO_MINALIGN), the slab allocator > > will return memory aligned to CRYPTO_MINALIGN even if > > ARCH_KMALLOC_MINALIGN is smaller. > > No we don't align the size to CRYPTO_MINALIGN at all. We simply > assume that this is the alignment returned by kmalloc. > > > Would the crypto code, say, do a kmalloc(64) and expect a 128 byte > > alignment (when CRYPTO_MINALIGN == 128)? Or does it align the size to > > CRYPTO_MINALIGN and do a kmalloc(128) directly? If it's the latter, I > > don't think there's a problem. > > It's the former. Does this only matter for DMA? If there other unrelated alignment requirements, I think those drivers should be fixed for their own cra_alignmask independent of the CPU cache line and DMA needs (e.g. some 1024-bit vectors that would benefit from an aligned load). With this series, the dynamic arch_kmalloc_minalign() still provides the DMA-safe alignment even if it would be smaller than the default CRYPTO_MINALIGN of 128. Let's say we have a structure: struct crypto_something { u8 some_field; u8 data[] CRYPTO_MINALIGN_ATTR; }; The sizeof(struct crypto_something) is automatically a multiple of CRYPTO_MINALIGN (128 bytes for arm64). While kmalloc() could return a smaller alignment, arch_kmalloc_minalign(), the data pointer above is still aligned to arch_kmalloc_minalign() and DMA-safe since CRYPTO_MINALIGN is a multiple of this (similar to the struct devres case, https://lore.kernel.org/all/YlRn2Wal4ezjvomZ@arm.com/). Even if such struct is included in another struct, the alignment and sizeof is inherited by the containing object. So let's assume the driver needs 64 bytes of data in addition to the struct, it would allocate: kmalloc(sizeof(struct crypto_something) + 64); Prior to this series, kmalloc() would return a 256-byte aligned pointer. With this series, if the cache line size on a SoC is 64-byte, the allocation falls under the kmalloc-192 cache, so 'data' would be 64-byte aligned which is safe for DMA. > I think you can still make the change you want, but first you need > to modify the affected drivers to specify their actual alignment > requirement explicitly through cra_alignmask and then use the > correct methods to access the context pointer. At a quick grep, most cra_alignmask values are currently 15 or smaller. I'm not convinced the driver needs to know about the CPU cache alignment. We could set cra_alignmask to CRYPTO_MINALIGN but that would incur unnecessary overhead via function like setkey_unaligned() when the arch_kmalloc_minalign() was already sufficient for DMA safety. Maybe I miss some use-cases or I focus too much on DMA safety. Thanks. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel