Re: [PATCH 1/2] Revert "swiotlb: fix info leak with DMA_FROM_DEVICE"

[Halil Pasic <pasic@linux.ibm.com>]

On Fri, 4 Mar 2022 17:55:40 +0100
Greg KH <gregkh@linuxfoundation.org> wrote:

> On Fri, Mar 04, 2022 at 05:34:47PM +0100, Halil Pasic wrote:
> > On Fri, 4 Mar 2022 15:28:44 +0100
> > Greg KH <gregkh@linuxfoundation.org> wrote:
> >   
> > > On Fri, Mar 04, 2022 at 02:58:58PM +0100, Halil Pasic wrote:  
> > > > This reverts commit ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e.    
> > > 
> > > Why???  
> > 
> > TLDR; We got v4 merged instead of v7  
> 
> That makes no sense at all to me, you need to describe it in detail.
> 
> You know better than this :(
> 

I have described the why in the cover letter of the series. Let me
copy-paste it here:

Unfortunately, we ended up with the wrong version of the patch "fix info
leak with DMA_FROM_DEVICE" getting merged. We got v4 merged, but the
version we want is v7 with some minor tweaks which were supposed to be
applied by Christoph (swiotlb maintainer). After pointing this out, I
was asked by Christoph to create an incremental fix. 

IMHO the cleanest way to do this is a reverting the incorrect version
of the patch and applying the correct one. I hope that qualifies as
an incremental fix.

The main differences between what we got and what we need are:
* swiotlb_sync_single_for_device is also required to do an extra bounce
* It was decided that we want to defer introducing DMA_ATTR_OVERWRITE,
  until we have exploiters 
* And anyway DMA_ATTR_OVERWRITE must take precedence over
  DMA_ATTR_SKIP_CPU_SYNC, so the v4 implementation of DMA_ATTR_OVERWRITE
  ain't even correct.

Describing it in the revert commit would have been a wiser choice, I
agree.

BTW the consensus seems to be, that a revert should be avoided, so I will
send a single-patch version of this fix soon(ish).

Sorry for the inconvenience!

Regards,
Halil