On Tue, Mar 22, 2022 at 11:02:18AM +0100, Halil Pasic wrote:
> Unfortunately, we ended up merging an old version of the patch "fix info
> leak with DMA_FROM_DEVICE" instead of merging the latest one. Christoph
> (the swiotlb maintainer), he asked me to create an incremental fix
> (after I have pointed this out the mix up, and asked him for guidance).
> So here we go.
>
> The main differences between what we got and what was agreed are:
> * swiotlb_sync_single_for_device is also required to do an extra bounce
> * We decided not to introduce DMA_ATTR_OVERWRITE until we have exploiters
> * The implantation of DMA_ATTR_OVERWRITE is flawed: DMA_ATTR_OVERWRITE
> must take precedence over DMA_ATTR_SKIP_CPU_SYNC
>
> Thus this patch removes DMA_ATTR_OVERWRITE, and makes
> swiotlb_sync_single_for_device() bounce unconditionally (that is, also
> when dir == DMA_TO_DEVICE) in order do avoid synchronising back stale
> data from the swiotlb buffer.
>
> Let me note, that if the size used with dma_sync_* API is less than the
> size used with dma_[un]map_*, under certain circumstances we may still
> end up with swiotlb not being transparent. In that sense, this is no
> perfect fix either.
>
> To get this bullet proof, we would have to bounce the entire
> mapping/bounce buffer. For that we would have to figure out the starting
> address, and the size of the mapping in
> swiotlb_sync_single_for_device(). While this does seem possible, there
> seems to be no firm consensus on how things are supposed to work.
>
> Signed-off-by: Halil Pasic <pasic@xxxxxxxxxxxxx>
> Fixes: ddbd89deb7d3 ("swiotlb: fix info leak with DMA_FROM_DEVICE")
> Cc: stable@xxxxxxxxxxxxxxx
> Reviewed-by: Christoph Hellwig <hch@xxxxxx>
> Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> [pasic@xxxxxxxxxxxxx: adapted for 5.10]
> ---
> Documentation/core-api/dma-attributes.rst | 8 --------
> include/linux/dma-mapping.h | 8 --------
> kernel/dma/swiotlb.c | 25 +++++++++++++++--------
> 3 files changed, 16 insertions(+), 25 deletions(-)
What is the git commit id of this commit in Linus's tree?
thanks,
greg k-h
