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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B092C433F5 for ; Sun, 27 Mar 2022 18:02:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232626AbiC0SEO (ORCPT ); Sun, 27 Mar 2022 14:04:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232196AbiC0SEO (ORCPT ); Sun, 27 Mar 2022 14:04:14 -0400 Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E71B344F4 for ; Sun, 27 Mar 2022 11:02:35 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id s25so16421926lji.5 for ; Sun, 27 Mar 2022 11:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OQOFDrIFh2bz70XHqIr89KbFLDHUuV5VP66dlTu2bGw=; b=UaVNLwcZnvNLhG+fejMyq3YjMXYSMxy5CO44s6uUwA0vwEwVOizoIns9xkanN7LLp0 W1vSRjwHVhQ+ttok6Z7J+uole/YvctKvrH6MJNpHghzdUIo/cKLR1r4McGrH4Vruxf7W HID+h3OJaj/oQ34G67d/vgqL0v6Fwqnq6rLSY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OQOFDrIFh2bz70XHqIr89KbFLDHUuV5VP66dlTu2bGw=; b=ZTa0NdH3hJXAPlUU+RsXf5eJM5F3g+1+WvoR+6BA0RGB7nma0aEQWdDdxb8jMlMreT lU6iNGLoYkhcXP7a5sbI3a57FuJN/dgasAVIeE+9vBHGs4R/REoAa+ECqpsA5glTLWpx oCTdqTxux98bmlkRLw/TxKUac1xy7WxcRS7UKNww+jbC8JUb8zZDx06ZFfc3VeuPrEHg Ux3rybOmmPC/P5ZNtLwGSTqR7XSkm1vAPviPmXjI4e8Oe4ogVjbMEqyDYbRetT628Lt5 N4cf0uttp0pd7wKxg7iqkaVxpTbYjuWTuJJO+qgZrhU+5la39yghrydKRIfaHpbpufhx RRrA== X-Gm-Message-State: AOAM531TgRBgFxRBeSqYJd2tnBBtFcIpaiKAZwlqzUL3CuQbz+Ri610i +7N0OCNTY0HvRGU7nC460vyxlytSN53Yy8QAAdQ= X-Google-Smtp-Source: ABdhPJxszGr8Hg3Fw/4ogeTiZKgP1pqN9+l+zs04OXlz/RaNNl4S/ovRY5ir6WfkL6MfMludD3hSeQ== X-Received: by 2002:a2e:6e0d:0:b0:247:fc9c:284e with SMTP id j13-20020a2e6e0d000000b00247fc9c284emr17181746ljc.251.1648404152650; Sun, 27 Mar 2022 11:02:32 -0700 (PDT) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com. [209.85.167.43]) by smtp.gmail.com with ESMTPSA id d16-20020a2eb050000000b002461d8f365bsm1478402ljl.38.2022.03.27.11.02.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Mar 2022 11:02:30 -0700 (PDT) Received: by mail-lf1-f43.google.com with SMTP id bt26so21194570lfb.3 for ; Sun, 27 Mar 2022 11:02:29 -0700 (PDT) X-Received: by 2002:a05:6512:3d8f:b0:44a:2c65:8323 with SMTP id k15-20020a0565123d8f00b0044a2c658323mr16370626lfv.52.1648404149184; Sun, 27 Mar 2022 11:02:29 -0700 (PDT) MIME-Version: 1.0 References: <20220325150419.757836392@linuxfoundation.org> <20220325150420.085364078@linuxfoundation.org> In-Reply-To: From: Linus Torvalds Date: Sun, 27 Mar 2022 11:02:12 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 5.10 11/38] swiotlb: rework "fix info leak with DMA_FROM_DEVICE" To: Greg Kroah-Hartman Cc: Linux Kernel Mailing List , stable , Halil Pasic , Christoph Hellwig Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Sun, Mar 27, 2022 at 2:30 AM Greg Kroah-Hartman wrote: > > But why did you just revert that commit, and not the previous one (i.e. > the one that this one "fixes")? Shouldn't ddbd89deb7d3 ("swiotlb: fix > info leak with DMA_FROM_DEVICE") also be dropped? The previous one wasn't obviously broken, and while it's a bit ugly, it doesn't have the fundamental issues that the "fix" commit had. And it does fix the whole "bounce buffer contents are undefined, and can get copied back later" at the bounce buffer allocation (well, "mapping") stage. Which could cause wasted CPU cycles and isn't great, but should fix the stale content thing for at least the common "map DMA, do DMA, unmap" situation. What commit aa6f8dcbab47 tried to fix was the "do multiple DMA sequences using one single mapping" case, but that's also what then broke ath9k because it really does want to do exactly that, but it very much needs to do it using the same buffer with no "let's reset it". So I think you're fine to drop ddbd89deb7d3 too, but that commit doesn't seem *wrong* per se. I do think we need some model for "clear the bounce buffer of stale data", and I do think that commit ddbd89deb7d3 probably isn't the final word, but we don't actually _have_ the final word on this all, so stable dropping it all is sane. But as mentioned, commit ddbd89deb7d3 can actually fix some cases. In particular, I do think it fixes the SG_IO data leak case that triggered the whole issue. It was just then the "let's expand on this fix" that was a disaster. Linus