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 45AD1C4332F for ; Fri, 25 Nov 2022 12:18:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 730916B0071; Fri, 25 Nov 2022 07:18:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6DFDD6B0072; Fri, 25 Nov 2022 07:18:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A81F6B0073; Fri, 25 Nov 2022 07:18:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 480126B0071 for ; Fri, 25 Nov 2022 07:18:14 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 05F51408A9 for ; Fri, 25 Nov 2022 12:18:14 +0000 (UTC) X-FDA: 80171866908.16.4F50BDD Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf20.hostedemail.com (Postfix) with ESMTP id 5EF0A1C000E for ; Fri, 25 Nov 2022 12:18: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 ams.source.kernel.org (Postfix) with ESMTPS id 6D277B82A88 for ; Fri, 25 Nov 2022 12:18:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A3887C43146 for ; Fri, 25 Nov 2022 12:18:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669378688; bh=2QQ3gkT8M4ne/f/6SMJfPCcoYNo2dNjFDj4PF9DSWIc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=HurY4q/yF+peulV7cvOO7tegNpqJMAftwxJ/HfA90kCJRh5gKLHbacaMXDqq4TBBF UnZJqEzFBWuFNipA/KgLMK7QPG1SIOaKjAU1NW5bQ/rB87Hwbz0LDOXjl81jbkaOR7 xq4peTK2aiu/PiYMyds1P5XvlAZNzJhc4K7/xPDpdmU2e82pfQCBhYel2eSN0JfJLC 3Ue3BuPUJWq11QwyzHluDrzKqvVgYUFHJn3jgZLozJOQKSxWtkW37sh3rZj1zbYdrt sjSkueGKaQ5qeJYk1l7CC+09XMVJM2576vH2pHzGbL+NI+ySnJSEtHauEdXTG+HVr1 6PMqs4Dr3V1Og== Received: by mail-lj1-f177.google.com with SMTP id n1so288142ljg.3 for ; Fri, 25 Nov 2022 04:18:08 -0800 (PST) X-Gm-Message-State: ANoB5pnIPDcZxM1EXT5Pm1o97FkINMhd7891IwITLljQHkUJyKlGbcWQ eHmGkinWwHVxaRiu4ObH5xl0BAWEzffVQ2mTpNc= X-Google-Smtp-Source: AA0mqf6CxETx94Nasnco4cIEVleHJVePOuucHyZEljEzF94SI+7etB5m2ezhOcBypmHyucIqtfdrsFWGOcllieCaWAo= X-Received: by 2002:a2e:95d2:0:b0:277:96a:5c32 with SMTP id y18-20020a2e95d2000000b00277096a5c32mr11115105ljh.415.1669378686498; Fri, 25 Nov 2022 04:18:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ard Biesheuvel Date: Fri, 25 Nov 2022 13:17:55 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [v2 PATCH 0/9] crypto: Add helpers for allocating with DMA alignment 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" , Linux Crypto Mailing List Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669378692; a=rsa-sha256; cv=none; b=m9Da2ApP39E70Eu0hA8ghQGBAXdMVvGN9pks09aKNAeNXCOJm1updeUbTlx9V8UxqIctSb m+X/LRMIUvoz8cxsFgT3Hwb+BoIBuV+856/GP/Fcc19CIjXlnLoZRO38dIMzLmNllhXoyO 7HuD7QqTg/IHV9nEiutwGebEPbI0SpM= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="HurY4q/y"; spf=pass (imf20.hostedemail.com: domain of ardb@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669378692; 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:dkim-signature; bh=2QQ3gkT8M4ne/f/6SMJfPCcoYNo2dNjFDj4PF9DSWIc=; b=kaUkDEcNHyP6lYQ7YuSGqEDcm9V8YVRHS4QWFFNQH2euJwaBPHI156MbG8NUJrWiV67tdd FRcSciX7CzPUmpQU+J66U7JZMWVgmloXdsC2DF+TLeWQ5up9sEiqDCZzBqbrXZaFdobOur Ynr3IqPGqqoCLxsYePW/j2irjNK1Xxo= X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="HurY4q/y"; spf=pass (imf20.hostedemail.com: domain of ardb@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: 8bhw5cmtn4dfgeupz6qctk91kqwnf8m3 X-Rspamd-Queue-Id: 5EF0A1C000E X-Rspamd-Server: rspam12 X-HE-Tag: 1669378692-162647 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, 25 Nov 2022 at 05:35, Herbert Xu wrote: > > This patch series adds helpers to allow drivers to explicitly > request ARCH_DMA_MINALIGN when allocating memory through the > Crypto API. > > Note that I've only converted one file in one driver as this > is only meant to show how it's done and find out what else we > may need. > > Other drivers will be added later. > Hi Herbert, This approach seems conceptually similar to what I proposed a while ago: https://lore.kernel.org/all/20220406142715.2270256-1-ardb@kernel.org/ If we agree that creating a distinction between ordinary allocations and ones that are rounded up to DMA alignment is ok, I wonder if we could minimize the churn by simply choosing between one or the other by taking the CRYPTO_ALG_ASYNC flag into account. On x86 and other arches that don't care about the distinction, none of this has any effect anyway. And on arm64, only hardware implementations use the CRYPTO_ALG_ASYNC flag, which makes its presence a reasonable heuristic to decide whether an algo implementation is backed by hardware that relies on DMA (the penalty for getting it wrong would be to use DMA ailgnment unnecessarily, which we already do today anyway) We'd still need changes in the generic crypto layer to distinguish the two cases, but we wouldn't need any changes to the drivers, which seems like a huge benefit to me