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 9EADFC433F5 for ; Fri, 15 Apr 2022 08:05:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2CD216B0071; Fri, 15 Apr 2022 04:05:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 27DB76B0073; Fri, 15 Apr 2022 04:05:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 16CB26B0074; Fri, 15 Apr 2022 04:05:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 07C326B0071 for ; Fri, 15 Apr 2022 04:05:37 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id BD5EA2607E for ; Fri, 15 Apr 2022 08:05:36 +0000 (UTC) X-FDA: 79358379072.01.EE93BA3 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf14.hostedemail.com (Postfix) with ESMTP id 1602B10000D for ; Fri, 15 Apr 2022 08:05:35 +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 AAFD4B82BA2 for ; Fri, 15 Apr 2022 08:05:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C4C52C385AB for ; Fri, 15 Apr 2022 08:05:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650009932; bh=riuuKXnoQlBRBV7zO25zHcF/JWwq7zfPNr5mu3m9+jI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=tXi9Jj5fnDgYEJrim5xfcMUIa9y+5BF6p9ZqnM7Q/aJgxGpwJRTGeSeibe2Y5Ezn1 teTDfS5nnAyKMU/ta+74JyWSeLIP6b0vZEqt5zWkyIVFKM3+0swjJv18a2cSQWQWqq IymLFV+D2iufYzMlVa94ag1HVsBOPhqflDvp4s7q4EBATTYae/zHKm9I0qr5DQXhq+ O3gLobRWXRaenBCExS0LOcP8DoW7qndV8GXQIUI6o8VBWak5jLP/LfgiimF9nZx3dj ieTcO471WheCh1GtnDnM5PCMP6nnZ1RBHzqfHMvWEGdMx24LHCdlY8kPryIqMxlDej +TVsRzXWf2zbQ== Received: by mail-oa1-f53.google.com with SMTP id 586e51a60fabf-e2fa360f6dso7551878fac.2 for ; Fri, 15 Apr 2022 01:05:32 -0700 (PDT) X-Gm-Message-State: AOAM530RvBudL+6KBciY0+lGbcNy70ObOoekn6BcdJfnrJaBW4qbTnTB z4xiLsLZ79wwi4NW4uAxlsLbIfJqbC017NlM0Ck= X-Google-Smtp-Source: ABdhPJwa5+CpOCKoPK7GU76i17Qy9CqHOdE4RymA/6S6MbMw45+zBMAYYJTH6M4NHw/fG0dhmipO+89okOHPFS+WrVU= X-Received: by 2002:a05:6870:eaa5:b0:da:b3f:2b45 with SMTP id s37-20020a056870eaa500b000da0b3f2b45mr1000528oap.228.1650009931924; Fri, 15 Apr 2022 01:05:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ard Biesheuvel Date: Fri, 15 Apr 2022 10:05:21 +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: rspam07 X-Rspamd-Queue-Id: 1602B10000D X-Stat-Signature: y4b5b9s5i9y4k6hbmri7zsoiajwjcg3o Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=tXi9Jj5f; spf=pass (imf14.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-HE-Tag: 1650009935-511489 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 09:52, Herbert Xu wrote: > > On Fri, Apr 15, 2022 at 09:49:12AM +0200, Ard Biesheuvel wrote: > > > > I'm not sure I understand what would go wrong if that assumption no > > longer holds. > > It's very simple, we don't do anything to the pointer returned > by kmalloc before returning it as a tfm or other object with > an alignment of CRYPTO_MINALIGN. IOW if kmalloc starts returning > pointers that are not aligned to CRYPTO_MINALIGN then we'd be > lying to the compiler. > 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.