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 CB785C433EF for ; Fri, 15 Apr 2022 10:22:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 430036B0071; Fri, 15 Apr 2022 06:22:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3DEEE6B0073; Fri, 15 Apr 2022 06:22:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2CE546B0074; Fri, 15 Apr 2022 06:22:43 -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 1EB7A6B0071 for ; Fri, 15 Apr 2022 06:22:43 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D4E64207EE for ; Fri, 15 Apr 2022 10:22:42 +0000 (UTC) X-FDA: 79358724564.24.AA4C5D7 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf14.hostedemail.com (Postfix) with ESMTP id 0E16C100004 for ; Fri, 15 Apr 2022 10:22:41 +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 1D09362225 for ; Fri, 15 Apr 2022 10:22:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F142C385AD for ; Fri, 15 Apr 2022 10:22:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650018160; bh=SG53jx5hbACDasyAwOVcOuCZSp72pRLMI6HQk8fNWEs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=dcw52qmWSkF0C9prN3DgM/DAnY31QNvXcaAJuTozCYDGH7UhMNRKVSfiFAfO2Pr8T 8aFOi99RO5C92uA7ePh4Z+TzNs1nzwOmEBSgG1MhiCcJhrp3+FySk256HAZWgMXkLW VUsRymlGVg4MwQTK3BMjlNgPZkT9aLq3G14tfOUCmJCTsWtxmRVgnBdtJTy7sxJRrE XWJHNxeFwhN20uORbqeEnDe4/qH081DJM3jA+g6cqWpEFeAX2izl3LN8M3amVZtoYd n2KfZjKTaUAA9GWOb1T5gY1YgF2UlnKyUsCFZbNKstXEJMCv1SUfDjYDLmHxvWabJX 34CCovi16nqxA== Received: by mail-oi1-f179.google.com with SMTP id z2so3654746oic.6 for ; Fri, 15 Apr 2022 03:22:40 -0700 (PDT) X-Gm-Message-State: AOAM533k3qV+6e09nLuniU8fA0RnYs53zCjY2kM4u9YSoDA+IBRMt658 pIaKue8Etr4EsHDwowVqw4L+zRBtygmgXtzjAes= X-Google-Smtp-Source: ABdhPJxd8R1jAfVjK9PZ0AEFBBqMoMB4bfX+Af0crm7iEuzlvmLYcmE08UUdz+HQf/1i+sTh/ULArtM0VA74n8EsNWA= X-Received: by 2002:a05:6808:1596:b0:2f7:5d89:eec7 with SMTP id t22-20020a056808159600b002f75d89eec7mr1320830oiw.228.1650018159669; Fri, 15 Apr 2022 03:22:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ard Biesheuvel Date: Fri, 15 Apr 2022 12:22:27 +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 Memory Management List , Linux ARM , Linux Kernel Mailing List , "David S. Miller" Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: ju11tkticej35b36uaadripoogpd4trt X-Rspam-User: Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=dcw52qmW; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf14.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 0E16C100004 X-HE-Tag: 1650018161-485007 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, 15 Apr 2022 at 12:12, Herbert Xu wrote: > > On Fri, Apr 15, 2022 at 11:51:49AM +0200, Ard Biesheuvel wrote: > > > > That is the whole point, really: ARCH_DMA_MINALIGN==128 does not mean > > __ctx needs to be aligned to 128 bytes, it only means that it should > > not share a 128 byte cacheline with the preceding fields. So if > > kmalloc() returns buffers that are aligned to whatever alignment the > > platform requires (which will be 64 in most cases), the above > > arrangement ensures that, without requiring that CRYPTO_MINALIGN == > > ARCH_DMA_MINALIGN. > > What if they started sharing a cacheline with the subsequent object? > I guess you could add some more padding at the end though. > Subsequent objects are owned by the driver, and it is the responsibility of the driver not to modify the fields while it is also mapped for DMA (and we have had issues in the past where drivers violated this rule). So as long as ARCH_KMALLOC_ALIGN guarantees actual DMA minimum alignment for both the start and the end, we shouldn't need any explicit padding at the end. > I could accept this as a temporary solution, if you volunteer to > modify all the affected drivers so we can get rid of this bandaid. > I'l do a scan of drivers/crypto to figure out how much we are relying on this to begin with.