|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [linux-linus test] 184722: regressions - FAIL
flight 184722 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/184722/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 6 kernel-build fail in 184721 REGR. vs. 184719 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-credit1 22 guest-start/debian.repeat fail pass in 184721 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-credit1 1 build-check(1) blocked in 184721 n/a test-arm64-arm64-xl-vhd 1 build-check(1) blocked in 184721 n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked in 184721 n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked in 184721 n/a test-arm64-arm64-examine 1 build-check(1) blocked in 184721 n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked in 184721 n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked in 184721 n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked in 184721 n/a test-arm64-arm64-xl 1 build-check(1) blocked in 184721 n/a test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184719 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184719 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184719 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184719 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184719 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184719 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184719 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184719 test-amd64-amd64-libvirt-xsm 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 15 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 15 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-check fail never pass test-arm64-arm64-xl 15 migrate-support-check fail never pass test-arm64-arm64-xl 16 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 15 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-check fail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-check fail never pass test-arm64-arm64-xl-vhd 14 migrate-support-check fail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 14 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-check fail never pass test-armhf-armhf-xl 16 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 15 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 15 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-check fail never pass test-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-check fail never pass version targeted for testing: linux 39133352cbed6626956d38ed72012f49b0421e7b baseline version: linux 9fc1ccccfd8d53dc7936fe6d633f2373fc9f62e8 Last test of basis 184719 2024-02-21 06:34:23 Z 1 days Testing same since 184721 2024-02-21 17:43:51 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: David Sterba <dsterba@xxxxxxxx> Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Jason Wang <jasowang@xxxxxxxxxx> Josef Bacik <josef@xxxxxxxxxxxxxx> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> Marc Zyngier <maz@xxxxxxxxxx> Michael S. Tsirkin <mst@xxxxxxxxxx> Nathan Chancellor <nathan@xxxxxxxxxx> # build Oliver Upton <oliver.upton@xxxxxxxxx> Paolo Bonzini <pbonzini@xxxxxxxxxx> Qu Wenruo <wqu@xxxxxxxx> zhenwei pi <pizhenwei@xxxxxxxxxxxxx> jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-amd64-dom0pvh-xl-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-freebsd11-amd64 pass test-amd64-amd64-freebsd12-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-examine-bios pass test-amd64-amd64-xl-credit1 fail test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-amd64-dom0pvh-xl-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-amd64-xl-pvshim pass test-amd64-amd64-pygrub pass test-amd64-amd64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-amd64-amd64-libvirt-raw pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-examine-uefi pass test-amd64-amd64-xl-vhd pass test-arm64-arm64-xl-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 39133352cbed6626956d38ed72012f49b0421e7b Merge: 8da8d88455eb c48617fbbe83 Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> Date: Wed Feb 21 09:13:27 2024 -0800 Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm Pull kvm fixes from Paolo Bonzini: "Two fixes for ARM ITS emulation. Unmapped interrupts were used instead of ignored, causing NULL pointer dereferences" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: arm64: vgic-its: Test for valid IRQ in MOVALL handler KVM: arm64: vgic-its: Test for valid IRQ in its_sync_lpi_pending_table() commit 8da8d88455ebbb4e05423cf60cff985e92d43754 Merge: d8be5a55b8e3 b0ad381fa769 Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> Date: Wed Feb 21 08:45:07 2024 -0800 Merge tag 'for-6.8-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: - Fix a deadlock in fiemap. There was a big lock around the whole operation that can interfere with a page fault and mkwrite. Reducing the lock scope can also speed up fiemap - Fix range condition for extent defragmentation which could lead to worse layout in some cases * tag 'for-6.8-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: fix deadlock with fiemap and extent locking btrfs: defrag: avoid unnecessary defrag caused by incorrect extent size commit d8be5a55b8e3f7eab8f36ceed2512f457f914318 Merge: 9fc1ccccfd8d c0ec2a712daf Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> Date: Wed Feb 21 08:37:49 2024 -0800 Merge tag 'v6.8-p4' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: "Fix a stack overflow in virtio" * tag 'v6.8-p4' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: virtio/akcipher - Fix stack overflow on memcpy commit c48617fbbe831d4c80fe84056033f17b70a31136 Merge: 9895ceeb5cd6 85a71ee9a070 Author: Paolo Bonzini <pbonzini@xxxxxxxxxx> Date: Wed Feb 21 05:18:56 2024 -0500 Merge tag 'kvmarm-fixes-6.8-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 fixes for 6.8, take #3 - Check for the validity of interrupts handled by a MOVALL command - Check for the validity of interrupts while reading the pending state on enabling LPIs. commit 85a71ee9a0700f6c18862ef3b0011ed9dad99aca Author: Oliver Upton <oliver.upton@xxxxxxxxx> Date: Wed Feb 21 09:27:32 2024 +0000 KVM: arm64: vgic-its: Test for valid IRQ in MOVALL handler It is possible that an LPI mapped in a different ITS gets unmapped while handling the MOVALL command. If that is the case, there is no state that can be migrated to the destination. Silently ignore it and continue migrating other LPIs. Cc: stable@xxxxxxxxxxxxxxx Fixes: ff9c114394aa ("KVM: arm/arm64: GICv4: Handle MOVALL applied to a vPE") Signed-off-by: Oliver Upton <oliver.upton@xxxxxxxxx> Link: https://lore.kernel.org/r/20240221092732.4126848-3-oliver.upton@xxxxxxxxx Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx> commit 8d3a7dfb801d157ac423261d7cd62c33e95375f8 Author: Oliver Upton <oliver.upton@xxxxxxxxx> Date: Wed Feb 21 09:27:31 2024 +0000 KVM: arm64: vgic-its: Test for valid IRQ in its_sync_lpi_pending_table() vgic_get_irq() may not return a valid descriptor if there is no ITS that holds a valid translation for the specified INTID. If that is the case, it is safe to silently ignore it and continue processing the LPI pending table. Cc: stable@xxxxxxxxxxxxxxx Fixes: 33d3bc9556a7 ("KVM: arm64: vgic-its: Read initial LPI pending table") Signed-off-by: Oliver Upton <oliver.upton@xxxxxxxxx> Link: https://lore.kernel.org/r/20240221092732.4126848-2-oliver.upton@xxxxxxxxx Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx> commit b0ad381fa7690244802aed119b478b4bdafc31dd Author: Josef Bacik <josef@xxxxxxxxxxxxxx> Date: Mon Feb 12 11:56:02 2024 -0500 btrfs: fix deadlock with fiemap and extent locking While working on the patchset to remove extent locking I got a lockdep splat with fiemap and pagefaulting with my new extent lock replacement lock. This deadlock exists with our normal code, we just don't have lockdep annotations with the extent locking so we've never noticed it. Since we're copying the fiemap extent to user space on every iteration we have the chance of pagefaulting. Because we hold the extent lock for the entire range we could mkwrite into a range in the file that we have mmap'ed. This would deadlock with the following stack trace [<0>] lock_extent+0x28d/0x2f0 [<0>] btrfs_page_mkwrite+0x273/0x8a0 [<0>] do_page_mkwrite+0x50/0xb0 [<0>] do_fault+0xc1/0x7b0 [<0>] __handle_mm_fault+0x2fa/0x460 [<0>] handle_mm_fault+0xa4/0x330 [<0>] do_user_addr_fault+0x1f4/0x800 [<0>] exc_page_fault+0x7c/0x1e0 [<0>] asm_exc_page_fault+0x26/0x30 [<0>] rep_movs_alternative+0x33/0x70 [<0>] _copy_to_user+0x49/0x70 [<0>] fiemap_fill_next_extent+0xc8/0x120 [<0>] emit_fiemap_extent+0x4d/0xa0 [<0>] extent_fiemap+0x7f8/0xad0 [<0>] btrfs_fiemap+0x49/0x80 [<0>] __x64_sys_ioctl+0x3e1/0xb50 [<0>] do_syscall_64+0x94/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 I wrote an fstest to reproduce this deadlock without my replacement lock and verified that the deadlock exists with our existing locking. To fix this simply don't take the extent lock for the entire duration of the fiemap. This is safe in general because we keep track of where we are when we're searching the tree, so if an ordered extent updates in the middle of our fiemap call we'll still emit the correct extents because we know what offset we were on before. The only place we maintain the lock is searching delalloc. Since the delalloc stuff can change during writeback we want to lock the extent range so we have a consistent view of delalloc at the time we're checking to see if we need to set the delalloc flag. With this patch applied we no longer deadlock with my testcase. CC: stable@xxxxxxxxxxxxxxx # 6.1+ Reviewed-by: Filipe Manana <fdmanana@xxxxxxxx> Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx> Reviewed-by: David Sterba <dsterba@xxxxxxxx> Signed-off-by: David Sterba <dsterba@xxxxxxxx> commit e42b9d8b9ea2672811285e6a7654887ff64d23f3 Author: Qu Wenruo <wqu@xxxxxxxx> Date: Wed Feb 7 10:00:42 2024 +1030 btrfs: defrag: avoid unnecessary defrag caused by incorrect extent size [BUG] With the following file extent layout, defrag would do unnecessary IO and result more on-disk space usage. # mkfs.btrfs -f $dev # mount $dev $mnt # xfs_io -f -c "pwrite 0 40m" $mnt/foobar # sync # xfs_io -f -c "pwrite 40m 16k" $mnt/foobar # sync Above command would lead to the following file extent layout: item 6 key (257 EXTENT_DATA 0) itemoff 15816 itemsize 53 generation 7 type 1 (regular) extent data disk byte 298844160 nr 41943040 extent data offset 0 nr 41943040 ram 41943040 extent compression 0 (none) item 7 key (257 EXTENT_DATA 41943040) itemoff 15763 itemsize 53 generation 8 type 1 (regular) extent data disk byte 13631488 nr 16384 extent data offset 0 nr 16384 ram 16384 extent compression 0 (none) Which is mostly fine. We can allow the final 16K to be merged with the previous 40M, but it's upon the end users' preference. But if we defrag the file using the default parameters, it would result worse file layout: # btrfs filesystem defrag $mnt/foobar # sync item 6 key (257 EXTENT_DATA 0) itemoff 15816 itemsize 53 generation 7 type 1 (regular) extent data disk byte 298844160 nr 41943040 extent data offset 0 nr 8650752 ram 41943040 extent compression 0 (none) item 7 key (257 EXTENT_DATA 8650752) itemoff 15763 itemsize 53 generation 9 type 1 (regular) extent data disk byte 340787200 nr 33292288 extent data offset 0 nr 33292288 ram 33292288 extent compression 0 (none) item 8 key (257 EXTENT_DATA 41943040) itemoff 15710 itemsize 53 generation 8 type 1 (regular) extent data disk byte 13631488 nr 16384 extent data offset 0 nr 16384 ram 16384 extent compression 0 (none) Note the original 40M extent is still there, but a new 32M extent is created for no benefit at all. [CAUSE] There is an existing check to make sure we won't defrag a large enough extent (the threshold is by default 32M). But the check is using the length to the end of the extent: range_len = em->len - (cur - em->start); /* Skip too large extent */ if (range_len >= extent_thresh) goto next; This means, for the first 8MiB of the extent, the range_len is always smaller than the default threshold, and would not be defragged. But after the first 8MiB, the remaining part would fit the requirement, and be defragged. Such different behavior inside the same extent caused the above problem, and we should avoid different defrag decision inside the same extent. [FIX] Instead of using @range_len, just use @em->len, so that we have a consistent decision among the same file extent. Now with this fix, we won't touch the extent, thus not making it any worse. Reported-by: Filipe Manana <fdmanana@xxxxxxxx> Fixes: 0cb5950f3f3b ("btrfs: fix deadlock when reserving space during defrag") CC: stable@xxxxxxxxxxxxxxx # 6.1+ Reviewed-by: Boris Burkov <boris@xxxxxx> Reviewed-by: Filipe Manana <fdmanana@xxxxxxxx> Signed-off-by: Qu Wenruo <wqu@xxxxxxxx> Signed-off-by: David Sterba <dsterba@xxxxxxxx> commit c0ec2a712daf133d9996a8a1b7ee2d4996080363 Author: zhenwei pi <pizhenwei@xxxxxxxxxxxxx> Date: Tue Jan 30 19:27:40 2024 +0800 crypto: virtio/akcipher - Fix stack overflow on memcpy sizeof(struct virtio_crypto_akcipher_session_para) is less than sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from stack variable leads stack overflow. Clang reports this issue by commands: make -j CC=clang-14 mrproper >/dev/null 2>&1 make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtio_crypto_akcipher_algs.o Fixes: 59ca6c93387d ("virtio-crypto: implement RSA algorithm") Link: https://lore.kernel.org/all/0a194a79-e3a3-45e7-be98-83abd3e1cb7e@xxxxxxxxxxxx/ Cc: <stable@xxxxxxxxxxxxxxx> Signed-off-by: zhenwei pi <pizhenwei@xxxxxxxxxxxxx> Tested-by: Nathan Chancellor <nathan@xxxxxxxxxx> # build Acked-by: Michael S. Tsirkin <mst@xxxxxxxxxx> Acked-by: Jason Wang <jasowang@xxxxxxxxxx> Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |