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 6439DC433EF for ; Mon, 28 Mar 2022 08:21:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238026AbiC1IXY (ORCPT ); Mon, 28 Mar 2022 04:23:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34162 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233675AbiC1IXX (ORCPT ); Mon, 28 Mar 2022 04:23:23 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CC80053704; Mon, 28 Mar 2022 01:21:42 -0700 (PDT) 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 sin.source.kernel.org (Postfix) with ESMTPS id 48F92CE1268; Mon, 28 Mar 2022 08:21:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F124C004DD; Mon, 28 Mar 2022 08:21:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1648455699; bh=rGS3hg/MsslSpTPtajHfguVHB2camyQ2cJ7EAOHchlQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qs/+XN8V+cYmkweV7abKvrL3IsgVrtYiptavboQsW+qhYyMmfxoKl0neGLCXm9zJj RbBpQ8TA2CzS7ZzzfNa4B7e5ffpc7zwQ2SjLlxqXaHUcj30lA+q/FN3zgXl9m2wFHp 9/GdzpUMeyVxruRswzKx1YEX8m7y08yBYLqWm5JQ= Date: Mon, 28 Mar 2022 10:21:37 +0200 From: Greg Kroah-Hartman To: Linus Torvalds Cc: Linux Kernel Mailing List , stable , Halil Pasic , Christoph Hellwig Subject: Re: [PATCH 5.10 11/38] swiotlb: rework "fix info leak with DMA_FROM_DEVICE" Message-ID: References: <20220325150419.757836392@linuxfoundation.org> <20220325150420.085364078@linuxfoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 27, 2022 at 11:02:12AM -0700, Linus Torvalds wrote: > 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. Ok, I have just queued that one up now for the older kernels, and the revert for 5.15 and newer, thanks. greg k-h