# 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 # 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 # Reported-by: Olha Cherevyk # Cc: Halil Pasic # Cc: Christoph Hellwig # Cc: Kalle Valo # Cc: Robin Murphy # Cc: Toke Høiland-Jørgensen # Cc: Maxime Bizon # Cc: Johannes Berg # Signed-off-by: Linus Torvalds # < /opt/cross/kisskb/korg/gcc-11.1.0-nolibc/sparc64-linux/bin/sparc64-linux-gcc --version # < /opt/cross/kisskb/korg/gcc-11.1.0-nolibc/sparc64-linux/bin/sparc64-linux-ld --version # < git log --format=%s --max-count=1 bddac7c1e02ba47f0570e494c9289acea3062cc1 # < make -s -j 32 ARCH=sparc64 O=/kisskb/build/linus_sparc64-defconfig_sparc64-gcc11 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-11.1.0-nolibc/sparc64-linux/bin/sparc64-linux- defconfig # < make -s -j 32 ARCH=sparc64 O=/kisskb/build/linus_sparc64-defconfig_sparc64-gcc11 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-11.1.0-nolibc/sparc64-linux/bin/sparc64-linux- help # make -s -j 32 ARCH=sparc64 O=/kisskb/build/linus_sparc64-defconfig_sparc64-gcc11 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-11.1.0-nolibc/sparc64-linux/bin/sparc64-linux- olddefconfig # make -s -j 32 ARCH=sparc64 O=/kisskb/build/linus_sparc64-defconfig_sparc64-gcc11 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-11.1.0-nolibc/sparc64-linux/bin/sparc64-linux- :1517:2: warning: #warning syscall clone3 not implemented [-Wcpp] WARNING: modpost: EXPORT symbol "_mcount" [vmlinux] version ... Is "_mcount" prototyped in ? kernel: arch/sparc/boot/image is ready kernel: arch/sparc/boot/zImage is ready Completed OK # rm -rf /kisskb/build/linus_sparc64-defconfig_sparc64-gcc11 # Build took: 0:01:58.639232