Buildresult: linus/xtensa-defconfig/xtensa-gcc8 built on Mar 27 2022, 07:03

kisskb

Revisions | Branches | Compilers | Configs | Build Results | Build Failures |

Status:	OK
Date/Time:	Mar 27 2022, 07:03
Duration:	0:00:16.630124
Builder:	ka4
Revision:	Revert "swiotlb: rework "fix info leak with DMA_FROM_DEVICE"" (`bddac7c1e02ba47f0570e494c9289acea3062cc1)`
Target:	linus/xtensa-defconfig/xtensa-gcc8
Branch:	linus
Compiler:	xtensa-gcc8 (xtensa-linux-gcc.br_real (Buildroot 2016.11-git-00613-ge98b4dd) 5.4.0 / GNU ld (GNU Binutils) 2.26.1)
Config:	defconfig (download)
Log:	Download original No warnings found in log. Full Log # git rev-parse -q --verify bddac7c1e02ba47f0570e494c9289acea3062cc1^{commit} bddac7c1e02ba47f0570e494c9289acea3062cc1 already have revision, skipping fetch # git checkout -q -f -B kisskb bddac7c1e02ba47f0570e494c9289acea3062cc1 # git clean -qxdf # < git log -1 # commit bddac7c1e02ba47f0570e494c9289acea3062cc1 # Author: Linus Torvalds <torvalds@linux-foundation.org> # Date: Sat Mar 26 10:42:04 2022 -0700 # # Revert "swiotlb: rework "fix info leak with DMA_FROM_DEVICE"" # # This reverts commit aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13. # # It turns out this breaks at least the ath9k wireless driver, and # possibly others. # # What the ath9k driver does on packet receive is to set up the DMA # transfer with: # # int ath_rx_init(..) # .. # bf->bf_buf_addr = dma_map_single(sc->dev, skb->data, # common->rx_bufsize, # DMA_FROM_DEVICE); # # and then the receive logic (through ath_rx_tasklet()) will fetch # incoming packets # # static bool ath_edma_get_buffers(..) # .. # dma_sync_single_for_cpu(sc->dev, bf->bf_buf_addr, # common->rx_bufsize, DMA_FROM_DEVICE); # # ret = ath9k_hw_process_rxdesc_edma(ah, rs, skb->data); # if (ret == -EINPROGRESS) { # /let device gain the buffer again/ # dma_sync_single_for_device(sc->dev, bf->bf_buf_addr, # common->rx_bufsize, DMA_FROM_DEVICE); # return false; # } # # and it's worth noting how that first DMA sync: # # dma_sync_single_for_cpu(..DMA_FROM_DEVICE); # # is there to make sure the CPU can read the DMA buffer (possibly by # copying it from the bounce buffer area, or by doing some cache flush). # The iommu correctly turns that into a "copy from bounce bufer" so that # the driver can look at the state of the packets. # # In the meantime, the device may continue to write to the DMA buffer, but # we at least have a snapshot of the state due to that first DMA sync. # # But that _second_ DMA sync: # # dma_sync_single_for_device(..DMA_FROM_DEVICE); # # is telling the DMA mapping that the CPU wasn't interested in the area # because the packet wasn't there. In the case of a DMA bounce buffer, # that is a no-op. # # Note how it's not a sync for the CPU (the "for_device()" part), and it's # not a sync for data written by the CPU (the "DMA_FROM_DEVICE" part). # # Or rather, it _should_ be a no-op. That's what commit aa6f8dcbab47 # broke: it made the code bounce the buffer unconditionally, and changed # the DMA_FROM_DEVICE to just unconditionally and illogically be # DMA_TO_DEVICE. # # [ Side note: purely within the confines of the swiotlb driver it wasn't # entirely illogical: The reason it did that odd DMA_FROM_DEVICE -> # DMA_TO_DEVICE conversion thing is because inside the swiotlb driver, # it uses just a swiotlb_bounce() helper that doesn't care about the # whole distinction of who the sync is for - only which direction to # bounce. # # So it took the "sync for device" to mean that the CPU must have been # the one writing, and thought it meant DMA_TO_DEVICE. ] # # Also note how the commentary in that commit was wrong, probably due to # that whole confusion, claiming that the commit makes the swiotlb code # # "bounce unconditionally (that is, also # when dir == DMA_TO_DEVICE) in order do avoid synchronising back stale # data from the swiotlb buffer" # # which is nonsensical for two reasons: # # - that "also when dir == DMA_TO_DEVICE" is nonsensical, as that was # exactly when it always did - and should do - the bounce. # # - since this is a sync for the device (not for the CPU), we're clearly # fundamentally not coping back stale data from the bounce buffers at # all, because we'd be copying to the bounce buffers. # # So that commit was just very confused. It confused the direction of the # synchronization (to the device, not the cpu) with the direction of the # DMA (from the device). # # Reported-and-bisected-by: Oleksandr Natalenko <oleksandr@natalenko.name> # Reported-by: Olha Cherevyk <olha.cherevyk@gmail.com> # Cc: Halil Pasic <pasic@linux.ibm.com> # Cc: Christoph Hellwig <hch@lst.de> # Cc: Kalle Valo <kvalo@kernel.org> # Cc: Robin Murphy <robin.murphy@arm.com> # Cc: Toke Høiland-Jørgensen <toke@toke.dk> # Cc: Maxime Bizon <mbizon@freebox.fr> # Cc: Johannes Berg <johannes@sipsolutions.net> # Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> # < /opt/cross/kisskb/br-xtensa-full-2016.08-613-ge98b4dd/bin/xtensa-linux-gcc --version # < /opt/cross/kisskb/br-xtensa-full-2016.08-613-ge98b4dd/bin/xtensa-linux-ld --version # < git log --format=%s --max-count=1 bddac7c1e02ba47f0570e494c9289acea3062cc1 # < make -s -j 120 ARCH=xtensa O=/kisskb/build/linus_xtensa-defconfig_xtensa CROSS_COMPILE=/opt/cross/kisskb/br-xtensa-full-2016.08-613-ge98b4dd/bin/xtensa-linux- defconfig # < make -s -j 120 ARCH=xtensa O=/kisskb/build/linus_xtensa-defconfig_xtensa CROSS_COMPILE=/opt/cross/kisskb/br-xtensa-full-2016.08-613-ge98b4dd/bin/xtensa-linux- help # make -s -j 120 ARCH=xtensa O=/kisskb/build/linus_xtensa-defconfig_xtensa CROSS_COMPILE=/opt/cross/kisskb/br-xtensa-full-2016.08-613-ge98b4dd/bin/xtensa-linux- olddefconfig # make -s -j 120 ARCH=xtensa O=/kisskb/build/linus_xtensa-defconfig_xtensa CROSS_COMPILE=/opt/cross/kisskb/br-xtensa-full-2016.08-613-ge98b4dd/bin/xtensa-linux- Completed OK # rm -rf /kisskb/build/linus_xtensa-defconfig_xtensa # Build took: 0:00:16.630124

© Michael Ellerman 2006-2018.