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 2E68FC433EF for ; Thu, 14 Apr 2022 14:31:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7BD486B0071; Thu, 14 Apr 2022 10:31:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 744706B0073; Thu, 14 Apr 2022 10:31:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E6D56B0074; Thu, 14 Apr 2022 10:31:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 4D9396B0071 for ; Thu, 14 Apr 2022 10:31:14 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1A47C266FF for ; Thu, 14 Apr 2022 14:31:14 +0000 (UTC) X-FDA: 79355722068.20.EE5EF3C Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf09.hostedemail.com (Postfix) with ESMTP id 7E4A5140016 for ; Thu, 14 Apr 2022 14:31:12 +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 sin.source.kernel.org (Postfix) with ESMTPS id 3509FCE28D8 for ; Thu, 14 Apr 2022 14:31:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A1DFC385A5 for ; Thu, 14 Apr 2022 14:31:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1649946666; bh=sYuRIOKotPt+JjyagaULCK/sP+wsew5Z8mm0QqMhM8U=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=CcENbH42U2QOdZU6S5pxfFHY6fuFidAEmlWORZn+hRWfPmnkWM0khYKDmhmWy6nKE HcPJiYN36zT7FPyRqI0V7826IYn5fGdcB7FjOWRNIiZMsZ9NKVOz/Xb+18yc9jlnst XPIZRI5MU8cY+8TVgowcOOCe0R40qmduwyuSmhygD6MMJD0zhSDGUeWlvPg3K7PDdD joCzBvjrWmCk4tWQHRNgWUoTTqIXbJyUZYrMOqDAUB2YkBVCoN0Hp6UjATx0OPevoa Rne1FmfRBU/dGNko5Na1Q47migtPTwlGzi/qTui+cfR93RIXZL5oCA7dIMc/73MwHs eVqhUvvdEarLA== Received: by mail-oi1-f169.google.com with SMTP id z8so5578121oix.3 for ; Thu, 14 Apr 2022 07:31:06 -0700 (PDT) X-Gm-Message-State: AOAM533k0AO3DEvZBW81ASw2ohylwutitqammr4V0a/KX1G0Gj+bu1Po V+PBsv5ErgSCDhzrV0z5YZUaVtP+bHf1LdCZLYQ= X-Google-Smtp-Source: ABdhPJz6vfhd6nZ73pd/JDo+zGftnuoYPNZ+DV4zOFApTEqq9RxSmi4R5LkRk1Vo1z8OpRtEUvrOSBaG3sSVs89sbYs= X-Received: by 2002:a05:6808:1596:b0:2f7:5d89:eec7 with SMTP id t22-20020a056808159600b002f75d89eec7mr1816562oiw.228.1649946665844; Thu, 14 Apr 2022 07:31:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ard Biesheuvel Date: Thu, 14 Apr 2022 16:30:54 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN To: Catalin Marinas 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" Content-Type: text/plain; charset="UTF-8" X-Rspam-User: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=CcENbH42; spf=pass (imf09.hostedemail.com: domain of ardb@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 7E4A5140016 X-Stat-Signature: hio919aechixehzsepo9qqjroqap4mwk X-HE-Tag: 1649946672-109135 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 Wed, 13 Apr 2022 at 10:47, Catalin Marinas wrote: .. > > Let's go back to restating the crypto code alignment requirements, as I > understand them (please correct): > > 1. Bus master accesses (DMA, CPUs that can't do efficient unaligned > accesses). That's what cra_alignmask is for. If there's a driver that > relies on an implicit kmalloc() alignment higher than cra_alignmask, > it is already broken on x86 and a few other architectures that don't > define ARCH_DMA_MINALIGN. But it won't be any worse with this series > since it only brings the arm64 kmalloc() alignment down from 128 to > 64. > > 2. Non-coherent DMA and cache invalidation. With my series, kmalloc'ed > buffers are DMA-safe for the CPU/SoC the kernel is running on. > > 3. DMA into buffers embedded in TFM structures. Since the offset of > those buffers is decided at compile-time, we need a > CRYPTO_MINALIGN_ATTR that covers both bus master alignment > requirements and the highest cache line size (CWG) for a non-coherent > DMA SoC. Ard's series would simplify the latter but, before then, > CRYPTO_MINALIGN needs to stay as the larger ARCH_DMA_MINALIGN. > > With my series, there is no change to the value of CRYPTO_MINALIGN for > arm64 or any other architecture, so point 3 is unaffected. The series > does change the kmalloc() alignment and that may be smaller than > CRYPTO_MINALIGN but neither of points 1 or 2 above are affected since > (a) we still have a sufficiently large ARCH_KMALLOC_MINALIGN of 64 and > (b) the kmalloc'ed buffers are safe for non-coherent DMA. > > Herbert, Ard, if I missed anything please let me know but based on my > understanding, this series is safe for the crypto code. > Agreed.