Buildresult: linus/parisc-allnoconfig/parisc-gcc8 built on Mar 27 2022, 06:59

kisskb

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

Status:	Failed
Date/Time:	Mar 27 2022, 06:59
Duration:	0:00:04.689919
Builder:	ka7
Revision:	Revert "swiotlb: rework "fix info leak with DMA_FROM_DEVICE"" (`bddac7c1e02ba47f0570e494c9289acea3062cc1)`
Target:	linus/parisc-allnoconfig/parisc-gcc8
Branch:	linus
Compiler:	parisc-gcc8 (hppa-linux-gcc (GCC) 8.1.0 / GNU ld (GNU Binutils) 2.30)
Config:	allnoconfig (download)
Log:	Download original Possible errors arch/parisc/kernel/vdso32/sigtramp.S:39: Error: unknown pseudo-op: `.proc' arch/parisc/kernel/vdso32/sigtramp.S:40: Error: unknown pseudo-op: `.callinfo' arch/parisc/kernel/vdso32/sigtramp.S:41: Error: unknown pseudo-op: `.entry' arch/parisc/kernel/vdso32/sigtramp.S:44: Error: no such instruction: `ldi 0,%r25' arch/parisc/kernel/vdso32/sigtramp.S:45: Error: no such instruction: `ldi 173,%r20' arch/parisc/kernel/vdso32/sigtramp.S:46: Error: no such instruction: `ble 0x100(%sr2,%r0)' arch/parisc/kernel/vdso32/sigtramp.S:49: Error: no such instruction: `ldi 1,%r25' arch/parisc/kernel/vdso32/sigtramp.S:50: Error: no such instruction: `ldi 173,%r20' arch/parisc/kernel/vdso32/sigtramp.S:51: Error: no such instruction: `ble 0x100(%sr2,%r0)' arch/parisc/kernel/vdso32/sigtramp.S:54: Error: unknown pseudo-op: `.exit' arch/parisc/kernel/vdso32/sigtramp.S:55: Error: unknown pseudo-op: `.procend' arch/parisc/kernel/vdso32/sigtramp.S:76: Error: unknown pseudo-op: `.stringz' arch/parisc/kernel/vdso32/restart_syscall.S:16: Error: bad or irreducible absolute expression arch/parisc/kernel/vdso32/restart_syscall.S:16: Error: junk at end of line, first unrecognized character is `:' arch/parisc/kernel/vdso32/restart_syscall.S:26: Error: no such instruction: `ldw 0(%sp),%r31' arch/parisc/kernel/vdso32/restart_syscall.S:29: Error: no such instruction: `be 0x100(%sr2,%r0)' arch/parisc/kernel/vdso32/restart_syscall.S:30: Error: no such instruction: `ldi 0,%r20' arch/parisc/kernel/vdso32/restart_syscall.S:32: Error: .cfi_endproc without corresponding .cfi_startproc make[2]: * [arch/parisc/kernel/vdso32/Makefile:34: arch/parisc/kernel/vdso32/sigtramp.o] Error 1 make[2]: * [arch/parisc/kernel/vdso32/Makefile:34: arch/parisc/kernel/vdso32/restart_syscall.o] Error 1 make[1]: * [arch/parisc/Makefile:177: vdso_prepare] Error 2 make: * [Makefile:219: __sub-make] Error 2 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/korg/gcc-8.1.0-nolibc/hppa-linux/bin/hppa-linux-gcc --version # < /opt/cross/kisskb/korg/gcc-8.1.0-nolibc/hppa-linux/bin/hppa-linux-ld --version # < git log --format=%s --max-count=1 bddac7c1e02ba47f0570e494c9289acea3062cc1 # < make -s -j 32 ARCH=parisc O=/kisskb/build/linus_parisc-allnoconfig_parisc-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/hppa-linux/bin/hppa-linux- allnoconfig # < make -s -j 32 ARCH=parisc O=/kisskb/build/linus_parisc-allnoconfig_parisc-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/hppa-linux/bin/hppa-linux- help # make -s -j 32 ARCH=parisc O=/kisskb/build/linus_parisc-allnoconfig_parisc-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/hppa-linux/bin/hppa-linux- olddefconfig # make -s -j 32 ARCH=parisc O=/kisskb/build/linus_parisc-allnoconfig_parisc-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/hppa-linux/bin/hppa-linux- /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Assembler messages: /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S:39: Error: unknown pseudo-op: `.proc' /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S:40: Error: unknown pseudo-op: `.callinfo' /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S:41: Error: unknown pseudo-op: `.entry' /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S:44: Error: no such instruction: `ldi 0,%r25' /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S:45: Error: no such instruction: `ldi 173,%r20' /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S:46: Error: no such instruction: `ble 0x100(%sr2,%r0)' /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S:49: Error: no such instruction: `ldi 1,%r25' /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S:50: Error: no such instruction: `ldi 173,%r20' /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S:51: Error: no such instruction: `ble 0x100(%sr2,%r0)' /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S:54: Error: unknown pseudo-op: `.exit' /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S:55: Error: unknown pseudo-op: `.procend' /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S:76: Error: unknown pseudo-op: `.stringz' /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Assembler messages: /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S:16: Error: bad or irreducible absolute expression /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S:16: Error: junk at end of line, first unrecognized character is `:' /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S:26: Error: no such instruction: `ldw 0(%sp),%r31' /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S:29: Error: no such instruction: `be 0x100(%sr2,%r0)' /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S:30: Error: no such instruction: `ldi 0,%r20' /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S:32: Error: .cfi_endproc without corresponding .cfi_startproc make[2]: * [/kisskb/src/arch/parisc/kernel/vdso32/Makefile:34: arch/parisc/kernel/vdso32/sigtramp.o] Error 1 make[2]: * Waiting for unfinished jobs.... make[2]: * [/kisskb/src/arch/parisc/kernel/vdso32/Makefile:34: arch/parisc/kernel/vdso32/restart_syscall.o] Error 1 make[1]: * [/kisskb/src/arch/parisc/Makefile:177: vdso_prepare] Error 2 make: *** [Makefile:219: __sub-make] Error 2 Command 'make -s -j 32 ARCH=parisc O=/kisskb/build/linus_parisc-allnoconfig_parisc-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/hppa-linux/bin/hppa-linux- ' returned non-zero exit status 2 # rm -rf /kisskb/build/linus_parisc-allnoconfig_parisc-gcc8 # Build took: 0:00:04.689919

© Michael Ellerman 2006-2018.