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 7E74DC433F5 for ; Sun, 2 Oct 2022 22:09:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6459D8E0002; Sun, 2 Oct 2022 18:09:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F4E58E0001; Sun, 2 Oct 2022 18:09:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 495A98E0002; Sun, 2 Oct 2022 18:09:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 352918E0001 for ; Sun, 2 Oct 2022 18:09:01 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E2EEC80404 for ; Sun, 2 Oct 2022 22:09:00 +0000 (UTC) X-FDA: 79977400440.03.495015B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf21.hostedemail.com (Postfix) with ESMTP id 6F5DA1C000F for ; Sun, 2 Oct 2022 22:09:00 +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 7146260F52 for ; Sun, 2 Oct 2022 22:08:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0609C4314C for ; Sun, 2 Oct 2022 22:08:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1664748538; bh=HfH4SXjoakBAXCnyUt76Zo2AktATIjMnXSVMSbQybwI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=skUXldGKEjsSoWONew9/z6Em/MECHl3mpGGkv9FrbVUHZwZ9kC0pLmEQtX++slog7 gorbTNqT6LY+1JEmP2ORe0mvtbJlQP9Gpx5ms6TnXCiAxwr+rSBizR6eeyaODCbbI0 nrTVslhUkbeeYkl2wWpQwsfsStcax13Ra6McM28l/Tt0/NqHVNH9bD7ilsDF8hk00u WTQgTznDp7QMWKeuHhI27ivlgyt7KNKP5SLQM5tVp81xxK1h4yJvAyiULUD8EC6qkm /C1PCC4npfhqjlTV8/uc65LbKRPZY3iN7XvKAQ4TAAaWIqHC9AYc4uJ6mUIZyIsWTH 9aDc+3wNjsMbQ== Received: by mail-lf1-f42.google.com with SMTP id j16so14202113lfg.1 for ; Sun, 02 Oct 2022 15:08:58 -0700 (PDT) X-Gm-Message-State: ACrzQf3XH8N7zk+OkLmSYFHBcSsC6W6NRDS6QCDyyI6y3A+yYMzQbSUR DLbpdhrPrm1reB1a3uZEXQY2NLodxkbjVyxr8wM= X-Google-Smtp-Source: AMsMyM6Vdy1cSlR/92G2FLcKbxMWKKMKNWEi8NpZ+BN5QLTAlj2FTfDhj9at3UkO+w7Eo8/0f3jY6CP2H/8+sRUOoi8= X-Received: by 2002:a19:c20b:0:b0:4a2:40e5:78b1 with SMTP id l11-20020a19c20b000000b004a240e578b1mr411616lfc.228.1664748535957; Sun, 02 Oct 2022 15:08:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ard Biesheuvel Date: Mon, 3 Oct 2022 00:08:43 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN To: Linus Torvalds Cc: Catalin Marinas , Isaac Manjarres , Herbert Xu , Will Deacon , Marc Zyngier , Arnd Bergmann , Greg Kroah-Hartman , Andrew Morton , Linux Memory Management List , Linux ARM , Linux Kernel Mailing List , "David S. Miller" , Saravana Kannan , kernel-team@android.com Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=skUXldGK; spf=pass (imf21.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664748540; a=rsa-sha256; cv=none; b=v86w+xRtJjrnCsqTAoX6m/74Nx7CgTKYaR8WoNMt5su7xGJTNEODoLL28BrvtuUOHgeX6a kFbEUDQG5J4F8b6wzMbS+ZWAOEP3ezkvr8pAy8RxKiEI1OLM3Yh1oQ/y9z9Z1X09NQYR19 DVyZcQvfXdO9MC5Gtbr9Z4T/Qba6WEM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664748540; 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=uHQJYN/m4RTMq382SFNcZ29dVno9Xk6EWkyV/FTNDgk=; b=46CsfzWpavxMFivZmMPP1bcZ1k1EVj4i11fXuKPDzEoDtAqO/09bTYUWyNKa8holnlNABM GVTKSCvVjTvNY+M1has6/FrE3JmUTxGACbaYczzb+/eIlbkrFtKWxXXUidH5WZYYjoaoWY bWnp03ut3LnCxIOw8dBm1QccC0FNjiY= X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 6F5DA1C000F X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=skUXldGK; spf=pass (imf21.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: au7x67jha9q44juwcrmaaoacefm499n1 X-HE-Tag: 1664748540-567441 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 Sun, 2 Oct 2022 at 19:00, Linus Torvalds wrote: > > On Sat, Oct 1, 2022 at 3:30 PM Catalin Marinas wrote: > > > > The "force bouncing" in my series currently only checks for small > > (potentially kmalloc'ed) sizes under the assumption that intra-object > > DMA buffers were properly aligned to 128. So for something like below: > > Ahh, so your forced bouncing isn't actually safe. > > I would have hoped (but obviously never checked) that the force > bouncing be made really safe and look at the actual alignment of the > DMA (comparing it to the hardware coherency requirements), so that > alignment at allocation time simply wouldn't matter. > > At that point, places like the ones you found would still work, they'd > just cause bouncing. > > At which point you'd then have a choice of > > (a) just let it bounce > > (b) marking the allocations that led to them > > and (a) might actually be perfectly fine in a lot of situations. Non-coherent DMA for networking is going to be fun, though. Fortunately, we'll only need to bounce for inbound DMA (where the cache invalidation might otherwise corrupt adjacent unrelated data), and for inbound networking, the driver typically owns and maps the buffers, and so in most cases, it can hopefully be easily modified to round up the allocations and the length values passed to dma_map_xxx(). And for outbound, we can just clean the SKB from the caches without the risk of corruption. It does mean that there is likely going to be a long tail of network drivers that will non-negligibly regress in performance and in memory footprint (as the entire RX ring will be double buffered all the time) until they get updated. -- Ard.