|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.1-testing test] 17724: regressions - FAIL
flight 17724 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/17724/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-oldkern 4 xen-build fail REGR. vs. 17718 build-amd64 4 xen-build fail REGR. vs. 17718 build-i386-oldkern 4 xen-build fail REGR. vs. 17718 build-i386 4 xen-build fail REGR. vs. 17718 Tests which did not succeed, but are not blocking: build-armhf 4 xen-build fail never pass test-amd64-amd64-xl-pcipt-intel 1 xen-build-check(1) blocked n/a test-i386-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-i386-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-sedf-pin 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-i386-i386-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 xen-build-check(1) blocked n/a test-i386-i386-xl-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a test-i386-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-i386-xend-qemut-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 1 xen-build-check(1) blocked n/a test-i386-i386-xl-qemut-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 1 xen-build-check(1) blocked n/a version targeted for testing: xen 21c31a811ca1705b71417fab520d9b39ae2ab3a7 baseline version: xen f4537b51116009bfb8359681a758ef5860cfd0db ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx> Marek Marczykowski <marmarek@xxxxxxxxxxxxxxxxxxxxxx> Paul Durrant <paul.durrant@xxxxxxxxxx> Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> ------------------------------------------------------------ jobs: build-amd64 fail build-armhf fail build-i386 fail build-amd64-oldkern fail build-i386-oldkern fail build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl blocked test-amd64-i386-xl blocked test-i386-i386-xl blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-win7-amd64 blocked test-amd64-i386-xl-win7-amd64 blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel blocked test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-i386-i386-pair blocked test-amd64-amd64-xl-sedf-pin blocked test-amd64-amd64-pv blocked test-amd64-i386-pv blocked test-i386-i386-pv blocked test-amd64-amd64-xl-sedf blocked test-amd64-i386-xl-qemut-winxpsp3-vcpus1 blocked test-amd64-i386-xl-winxpsp3-vcpus1 blocked test-amd64-i386-xend-qemut-winxpsp3 blocked test-amd64-amd64-xl-qemut-winxpsp3 blocked test-i386-i386-xl-qemut-winxpsp3 blocked test-amd64-amd64-xl-qemuu-winxpsp3 blocked test-i386-i386-xl-qemuu-winxpsp3 blocked test-amd64-i386-xend-winxpsp3 blocked test-amd64-amd64-xl-winxpsp3 blocked test-i386-i386-xl-winxpsp3 blocked ------------------------------------------------------------ sg-report-flight on woking.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 21c31a811ca1705b71417fab520d9b39ae2ab3a7 Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Thu Apr 18 17:44:17 2013 +0100 libxl: Fix SEGV in network-attach When "device/vif" directory exists but is empty l!=NULL, but nb==0, so l[nb-1] is invalid. Add missing check. Signed-off-by: Marek Marczykowski <marmarek@xxxxxxxxxxxxxxxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> (cherry picked from commit 9f1a6ff38b8e7bb97a016794115de28553a6559f) Conflicts: tools/libxl/libxl.c Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> commit a12ed396652c22988e0e7a3f5bd57c882872da8e Author: Paul Durrant <paul.durrant@xxxxxxxxxx> Date: Thu Apr 18 17:38:17 2013 +0200 Fix rcu domain locking for transitive grants When acquiring a transitive grant for copy then the owning domain needs to be locked down as well as the granting domain. This was being done, but the unlocking was not. The acquire code now stores the struct domain * of the owning domain (rather than the domid) in the active entry in the granting domain. The release code then does the unlock on the owning domain. Note that I believe I also fixed a bug where, for non-transitive grants the active entry contained a reference to the acquiring domain rather than the granting domain. From my reading of the code this would stop the release code for transitive grants from terminating its recursion correctly. Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> master commit: f544bf377ee829e1342abd818ac30478c6f3a134 master date: 2011-03-08 16:30:30 +0000 Also, for non-transitive grants we now avoid incorrectly recursing in __release_grant_for_copy. This is CVE-2013-1964 / XSA-50. Reported-by: Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Tested-by: Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx> commit d3d1288618ec903ad6a0e994ddfe0975cbac1584 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Thu Apr 18 16:24:08 2013 +0200 x86: fix various issues with handling guest IRQs - properly revoke IRQ access in map_domain_pirq() error path - don't permit replacing an in use IRQ - don't accept inputs in the GSI range for MAP_PIRQ_TYPE_MSI - track IRQ access permission in host IRQ terms, not guest IRQ ones (and with that, also disallow Dom0 access to IRQ0) This is CVE-2013-1919 / XSA-46. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> master commit: 545607eb3cfeb2abf5742d1bb869734f317fcfe5 master date: 2013-04-18 16:11:23 +0200 commit 584eb7c15e4c94baaba93468776572dd7373a33c Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Thu Apr 18 16:23:07 2013 +0200 x86: clear EFLAGS.NT in SYSENTER entry path ... as it causes problems if we happen to exit back via IRET: In the course of trying to handle the fault, the hypervisor creates a stack frame by hand, and uses PUSHFQ to set the respective EFLAGS field, but expects to be able to IRET through that stack frame to the second portion of the fixup code (which causes a #GP due to the stored EFLAGS having NT set). And even if this worked (e.g if we cleared NT in that path), it would then (through the fail safe callback) cause a #GP in the guest with the SYSENTER handler's first instruction as the source, which in turn would allow guest user mode code to crash the guest kernel. Inject a #GP on the fake (NULL) address of the SYSENTER instruction instead, just like in the case where the guest kernel didn't register a corresponding entry point. On 32-bit we also need to make sure we clear SYSENTER_CS for all CPUs (neither #RESET nor #INIT guarantee this). This is CVE-2013-1917 / XSA-44. Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Tested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: fdac9515607b757c044e7ef0d61b1453ef999b08 master date: 2013-04-18 16:00:35 +0200 (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |