|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [qemu-upstream-4.11-testing test] 134594: trouble: blocked/broken/fail/pass
flight 134594 qemu-upstream-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/134594/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops <job status> broken build-arm64 <job status> broken build-arm64-xsm <job status> broken build-arm64 4 host-install(4) broken REGR. vs. 125575 build-arm64-pvops 4 host-install(4) broken REGR. vs. 125575 build-arm64-xsm 4 host-install(4) broken REGR. vs. 125575 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuu 2871355a6957f1b3c16f858e3143e0fff0737b6a baseline version: qemuu 20c76f9a5fbf16d58c6add2ace2ff0fabd785926 Last test of basis 125575 2018-07-25 18:53:54 Z 260 days Testing same since 134270 2019-04-01 16:10:50 Z 10 days 5 attempts ------------------------------------------------------------ People who touched revisions under test: Anthony PERARD <anthony.perard@xxxxxxxxxx> Gerd Hoffmann <kraxel@xxxxxxxxxx> Greg Kurz <groug@xxxxxxxx> Jason Wang <jasowang@xxxxxxxxxx> Kevin Wolf <kwolf@xxxxxxxxxx> Li Qiang <liq3ea@xxxxxxxxx> Michael McConville <mmcco@xxxxxxxxxxx> Michael Tokarev <mjt@xxxxxxxxxx> Niels de Vos <ndevos@xxxxxxxxxx> Paolo Bonzini <pbonzini@xxxxxxxxxx> Peter Maydell <peter.maydell@xxxxxxxxxx> Philippe Mathieu-Daudé <philmd@xxxxxxxxxx> Prasanna Kumar Kalever <prasanna.kalever@xxxxxxxxxx> Roger Pau Monne <roger.pau@xxxxxxxxxx> Roger Pau Monné <roger.pau@xxxxxxxxxx> jobs: build-amd64-xsm pass build-arm64-xsm broken build-i386-xsm pass build-amd64 pass build-arm64 broken build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt blocked build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops broken build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-arm64-arm64-xl blocked test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-xl-qemuu-win10-i386 fail test-amd64-i386-xl-qemuu-win10-i386 fail test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-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-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-amd64-amd64-libvirt-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 broken-job build-arm64-pvops broken broken-job build-arm64 broken broken-job build-arm64-xsm broken broken-step build-arm64 host-install(4) broken-step build-arm64-pvops host-install(4) broken-step build-arm64-xsm host-install(4) Not pushing. ------------------------------------------------------------ commit 2871355a6957f1b3c16f858e3143e0fff0737b6a Author: Kevin Wolf <kwolf@xxxxxxxxxx> Date: Thu Oct 11 17:30:39 2018 +0200 gtk: Don't vte_terminal_set_encoding() on new VTE versions The function vte_terminal_set_encoding() is deprecated since VTE 0.54, so stop calling it from that version on. This fixes a build error because of our use of warning flags [-Werror=deprecated-declarations]. Fixes: https://bugs.launchpad.net/bugs/1794939 Reported-by: Bastian Koppelmann <kbastian@xxxxxxxxxxxxxxxxxxxxx> Signed-off-by: Kevin Wolf <kwolf@xxxxxxxxxx> Message-id: 20181011153039.2324-1-kwolf@xxxxxxxxxx Signed-off-by: Gerd Hoffmann <kraxel@xxxxxxxxxx> (cherry picked from commit 6415994ffcc6d22b3f5add67f63fe77e4b9711f4) commit 94a715b6cba7225e5db59901e5d0a5252ead9755 Author: Niels de Vos <ndevos@xxxxxxxxxx> Date: Tue Mar 5 16:46:34 2019 +0100 gluster: the glfs_io_cbk callback function pointer adds pre/post stat args The glfs_*_async() functions do a callback once finished. This callback has changed its arguments, pre- and post-stat structures have been added. This makes it possible to improve caching, which is useful for Samba and NFS-Ganesha, but not so much for QEMU. Gluster 6 is the first release that includes these new arguments. With an additional detection in ./configure, the new arguments can conditionally get included in the glfs_io_cbk handler. Signed-off-by: Niels de Vos <ndevos@xxxxxxxxxx> Signed-off-by: Kevin Wolf <kwolf@xxxxxxxxxx> (cherry picked from commit 0e3b891fefacc0e49f3c8ffa3a753b69eb7214d2) commit 13bac7abf60e25101ef6059f0da7a168942eccd9 Author: Prasanna Kumar Kalever <prasanna.kalever@xxxxxxxxxx> Date: Tue Mar 5 16:46:33 2019 +0100 gluster: Handle changed glfs_ftruncate signature New versions of Glusters libgfapi.so have an updated glfs_ftruncate() function that returns additional 'struct stat' structures to enable advanced caching of attributes. This is useful for file servers, not so much for QEMU. Nevertheless, the API has changed and needs to be adopted. Signed-off-by: Prasanna Kumar Kalever <prasanna.kalever@xxxxxxxxxx> Signed-off-by: Niels de Vos <ndevos@xxxxxxxxxx> Signed-off-by: Kevin Wolf <kwolf@xxxxxxxxxx> (cherry picked from commit e014dbe74e0484188164c61ff6843f8a04a8cb9d) commit 9864a12f4a13f19a7440cb32bd3242506d6b2738 Author: Jason Wang <jasowang@xxxxxxxxxx> Date: Tue Dec 4 11:53:43 2018 +0800 net: drop too large packet early We try to detect and drop too large packet (>INT_MAX) in 1592a9947036 ("net: ignore packet size greater than INT_MAX") during packet delivering. Unfortunately, this is not sufficient as we may hit another integer overflow when trying to queue such large packet in qemu_net_queue_append_iov(): - size of the allocation may overflow on 32bit - packet->size is integer which may overflow even on 64bit Fixing this by moving the check to qemu_sendv_packet_async() which is the entrance of all networking codes and reduce the limit to NET_BUFSIZE to be more conservative. This works since: - For the callers that call qemu_sendv_packet_async() directly, they only care about if zero is returned to determine whether to prevent the source from producing more packets. A callback will be triggered if peer can accept more then source could be enabled. This is usually used by high speed networking implementation like virtio-net or netmap. - For the callers that call qemu_sendv_packet() that calls qemu_sendv_packet_async() indirectly, they often ignore the return value. In this case qemu will just the drop packets if peer can't receive. Qemu will copy the packet if it was queued. So it was safe for both kinds of the callers to assume the packet was sent. Since we move the check from qemu_deliver_packet_iov() to qemu_sendv_packet_async(), it would be safer to make qemu_deliver_packet_iov() static to prevent any external user in the future. This is a revised patch of CVE-2018-17963. Cc: qemu-stable@xxxxxxxxxx Cc: Li Qiang <liq3ea@xxxxxxx> Fixes: 1592a9947036 ("net: ignore packet size greater than INT_MAX") Reported-by: Li Qiang <liq3ea@xxxxxxxxx> Reviewed-by: Li Qiang <liq3ea@xxxxxxxxx> Signed-off-by: Jason Wang <jasowang@xxxxxxxxxx> Reviewed-by: Thomas Huth <thuth@xxxxxxxxxx> Message-id: 20181204035347.6148-2-jasowang@xxxxxxxxxx Signed-off-by: Peter Maydell <peter.maydell@xxxxxxxxxx> (cherry picked from commit 25c01bd19d0e4b66f357618aeefda1ef7a41e21a) commit b697c0aecbf9bc8bdb4f1bf0ea92e6a8fb258094 Author: Jason Wang <jasowang@xxxxxxxxxx> Date: Wed May 30 13:16:36 2018 +0800 net: ignore packet size greater than INT_MAX There should not be a reason for passing a packet size greater than INT_MAX. It's usually a hint of bug somewhere, so ignore packet size greater than INT_MAX in qemu_deliver_packet_iov() CC: qemu-stable@xxxxxxxxxx Reported-by: Daniel Shapira <daniel@xxxxxxxxxxxxx> Reviewed-by: Michael S. Tsirkin <mst@xxxxxxxxxx> Signed-off-by: Jason Wang <jasowang@xxxxxxxxxx> (cherry picked from commit 1592a9947036d60dde5404204a5d45975133caf5) commit f517c1b6079a514c0798eacb3f7c77b9dd8ebbf1 Author: Greg Kurz <groug@xxxxxxxx> Date: Fri Nov 23 13:28:03 2018 +0100 9p: fix QEMU crash when renaming files When using the 9P2000.u version of the protocol, the following shell command line in the guest can cause QEMU to crash: while true; do rm -rf aa; mkdir -p a/b & touch a/b/c & mv a aa; done With 9P2000.u, file renaming is handled by the WSTAT command. The v9fs_wstat() function calls v9fs_complete_rename(), which calls v9fs_fix_path() for every fid whose path is affected by the change. The involved calls to v9fs_path_copy() may race with any other access to the fid path performed by some worker thread, causing a crash like shown below: Thread 12 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x0000555555a25da2 in local_open_nofollow (fs_ctx=0x555557d958b8, path=0x0, flags=65536, mode=0) at hw/9pfs/9p-local.c:59 59 while (*path && fd != -1) { (gdb) bt #0 0x0000555555a25da2 in local_open_nofollow (fs_ctx=0x555557d958b8, path=0x0, flags=65536, mode=0) at hw/9pfs/9p-local.c:59 #1 0x0000555555a25e0c in local_opendir_nofollow (fs_ctx=0x555557d958b8, path=0x0) at hw/9pfs/9p-local.c:92 #2 0x0000555555a261b8 in local_lstat (fs_ctx=0x555557d958b8, fs_path=0x555556b56858, stbuf=0x7fff84830ef0) at hw/9pfs/9p-local.c:185 #3 0x0000555555a2b367 in v9fs_co_lstat (pdu=0x555557d97498, path=0x555556b56858, stbuf=0x7fff84830ef0) at hw/9pfs/cofile.c:53 #4 0x0000555555a1e9e2 in v9fs_stat (opaque=0x555557d97498) at hw/9pfs/9p.c:1083 #5 0x0000555555e060a2 in coroutine_trampoline (i0=-669165424, i1=32767) at util/coroutine-ucontext.c:116 #6 0x00007fffef4f5600 in __start_context () at /lib64/libc.so.6 #7 0x0000000000000000 in () (gdb) The fix is to take the path write lock when calling v9fs_complete_rename(), like in v9fs_rename(). Impact: DoS triggered by unprivileged guest users. Fixes: CVE-2018-19489 Cc: P J P <ppandit@xxxxxxxxxx> Reported-by: zhibin hu <noirfate@xxxxxxxxx> Reviewed-by: Prasad J Pandit <pjp@xxxxxxxxxxxxxxxxx> Signed-off-by: Greg Kurz <groug@xxxxxxxx> (cherry picked from commit 1d20398694a3b67a388d955b7a945ba4aa90a8a8) commit 9af9c1c20e313f597168e0522f5fc8d78123b0c8 Author: Paolo Bonzini <pbonzini@xxxxxxxxxx> Date: Tue Nov 20 19:41:48 2018 +0100 nvme: fix out-of-bounds access to the CMB Because the CMB BAR has a min_access_size of 2, if you read the last byte it will try to memcpy *2* bytes from n->cmbuf, causing an off-by-one error. This is CVE-2018-16847. Another way to fix this might be to register the CMB as a RAM memory region, which would also be more efficient. However, that might be a change for big-endian machines; I didn't think this through and I don't know how real hardware works. Add a basic testcase for the CMB in case somebody does this change later on. Cc: Keith Busch <keith.busch@xxxxxxxxx> Cc: qemu-block@xxxxxxxxxx Reported-by: Li Qiang <liq3ea@xxxxxxxxx> Reviewed-by: Li Qiang <liq3ea@xxxxxxxxx> Tested-by: Li Qiang <liq3ea@xxxxxxxxx> Signed-off-by: Paolo Bonzini <pbonzini@xxxxxxxxxx> Reviewed-by: Philippe Mathieu-Daudé <philmd@xxxxxxxxxx> Tested-by: Philippe Mathieu-Daudé <philmd@xxxxxxxxxx> Signed-off-by: Kevin Wolf <kwolf@xxxxxxxxxx> (cherry picked from commit 87ad860c622cc8f8916b5232bd8728c08f938fce) commit c50c704a6a09554925b926c0313280be4a3d7100 Author: Greg Kurz <groug@xxxxxxxx> Date: Tue Nov 20 13:00:35 2018 +0100 9p: take write lock on fid path updates (CVE-2018-19364) Recent commit 5b76ef50f62079a fixed a race where v9fs_co_open2() could possibly overwrite a fid path with v9fs_path_copy() while it is being accessed by some other thread, ie, use-after-free that can be detected by ASAN with a custom 9p client. It turns out that the same can happen at several locations where v9fs_path_copy() is used to set the fid path. The fix is again to take the write lock. Fixes CVE-2018-19364. Cc: P J P <ppandit@xxxxxxxxxx> Reported-by: zhibin hu <noirfate@xxxxxxxxx> Reviewed-by: Prasad J Pandit <pjp@xxxxxxxxxxxxxxxxx> Signed-off-by: Greg Kurz <groug@xxxxxxxx> (cherry picked from commit 5b3c77aa581ebb215125c84b0742119483571e55) commit 03c28544a1b67fd48ef1fa72231818efa8563874 Author: Roger Pau Monne <roger.pau@xxxxxxxxxx> Date: Mon Mar 18 18:37:31 2019 +0100 xen-mapcache: use MAP_FIXED flag so the mmap address hint is always honored Or if it's not possible to honor the hinted address an error is returned instead. This makes it easier to spot the actual failure, instead of failing later on when the caller of xen_remap_bucket realizes the mapping has not been created at the requested address. Also note that at least on FreeBSD using MAP_FIXED will cause mmap to try harder to honor the passed address. Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Acked-by: Anthony PERARD <anthony.perard@xxxxxxxxxx> Reviewed-by: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx> Message-Id: <20190318173731.14494-1-roger.pau@xxxxxxxxxx> Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx> (cherry picked from commit 4158e93f4aced247c8db94a0275fc027da7dc97e) commit a35ed1444329599f2975512c82be795f8af284d5 Author: Michael McConville <mmcco@xxxxxxxxxxx> Date: Fri Dec 1 11:31:57 2017 -0700 mmap(2) returns MAP_FAILED, not NULL, on failure Signed-off-by: Michael McConville <mmcco@xxxxxxxxxxx> Reviewed-by: John Snow <jsnow@xxxxxxxxxx> Signed-off-by: Michael Tokarev <mjt@xxxxxxxxxx> (cherry picked from commit ab1ce9bd4897b9909836e2d50bca86f2f3f2dddc) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |