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 302FFC433EF for ; Fri, 15 Apr 2022 09:52:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8493F6B0073; Fri, 15 Apr 2022 05:52:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D2786B0074; Fri, 15 Apr 2022 05:52:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64C8B6B0075; Fri, 15 Apr 2022 05:52:05 -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 553216B0073 for ; Fri, 15 Apr 2022 05:52:05 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 22D9A25923 for ; Fri, 15 Apr 2022 09:52:05 +0000 (UTC) X-FDA: 79358647410.25.711AD23 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf03.hostedemail.com (Postfix) with ESMTP id 849BF20007 for ; Fri, 15 Apr 2022 09:52:04 +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 53ED7B82D97 for ; Fri, 15 Apr 2022 09:52:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A3BA3C385AD for ; Fri, 15 Apr 2022 09:52:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650016321; bh=EBREfv/xjXAG8CJUnZO7ZCNWHvcAy+bC2kvoVDVVtYc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=h0EaX/X5k7WmSIVOemIt7peeO6RSIhFLQqWNZUOaDwvJb/WWrn0u3GuhPJ2gBIhkb l89NprYd1bGn/OC7aMVxcQz1P5XR9c5XKQWBVOnfCGXTfv/jeaRzKuP9FpVVFXA6sU OigkrC9skcBc+F2iAgANxsyeMpr03WGe4v8g+KWsrfoam5eTJNA5g/m1sjdCXCayrZ lS/oqM0Or4YjXNwIWJ+0Kq1Nlm4xxH3g191uotr05Mcbve2EMH5kl6G9955mH/nXSs XxIJqQIRfQAniAaeHuDQXwwawJOPMZ9ZlkqptYsJAipUyppe7Roq7fZeAns4qvxIsQ wGHWSyu2AlS/A== Received: by mail-oi1-f172.google.com with SMTP id w127so7961895oig.10 for ; Fri, 15 Apr 2022 02:52:01 -0700 (PDT) X-Gm-Message-State: AOAM5317xaorRTP56iPi0pHtblUjdZR58OZGocAWgHt0thsNymEl8V/A tA4Hn2MjNRlTwOMn9/h/Cw8LBUbHmpiV4Cg8puk= X-Google-Smtp-Source: ABdhPJzfxPA7NNS7cW4dM9k9tJWX2bgF6Pn7vmwUazhuO8K52EFF/Tb9PCixdfwBv6/wsqRkxzcNQWit9ryEO2Vwvd4= X-Received: by 2002:a05:6808:1596:b0:2f7:5d89:eec7 with SMTP id t22-20020a056808159600b002f75d89eec7mr1279737oiw.228.1650016320681; Fri, 15 Apr 2022 02:52:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ard Biesheuvel Date: Fri, 15 Apr 2022 11:51:49 +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-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 849BF20007 X-Stat-Signature: dyyq1bco5mecg7x9pt9584c4mfo4yx97 Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="h0EaX/X5"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf03.hostedemail.com: domain of ardb@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=ardb@kernel.org X-HE-Tag: 1650016324-221145 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 10:12, Herbert Xu wrote: > > On Fri, Apr 15, 2022 at 10:05:21AM +0200, Ard Biesheuvel wrote: > > > > I guess that should be fixable. GIven that this is about padding > > rather than alignment, we could do something like > > > > struct crypto_request { > > union { > > struct { > > ... fields ... > > }; > > u8 __padding[ARCH_DMA_MINALIGN]; > > }; > > void __ctx[] __align(CRYPTO_MINALIGN); > > }; > > > > And then hopefully, we can get rid of the padding once we fix drivers > > doing non-cache coherent inbound DMA into those structures. > > Sorry, I don't think this works. kmalloc can still return something > that's not ARCH_DMA_MINALIGN-aligned, and therefore __ctx won't be > aligned correctly. > 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.