|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [libvirt test] 144244: regressions - FAIL
flight 144244 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/144244/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs. 144233 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 144233 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 144233 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check 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-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-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt d6064e2759a24e0802f363e3a810dc5a7d7ebb15 baseline version: libvirt 5e939cea896fb3373a6f68f86e325c657429ed3d Last test of basis 144233 2019-11-21 04:18:53 Z 1 days Testing same since 144244 2019-11-22 04:18:48 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> Erik Skultety <eskultet@xxxxxxxxxx> Jamie Strandboge <jamie@xxxxxxxxxxxxx> Ján Tomko <jtomko@xxxxxxxxxx> 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-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-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 d6064e2759a24e0802f363e3a810dc5a7d7ebb15 Author: Erik Skultety <eskultet@xxxxxxxxxx> Date: Mon Nov 18 12:04:16 2019 +0100 libvirt-<module>: Check caller-provided buffers to be NULL with size > 0 Pre-Glib era which used malloc allowed the size of the client-side buffers to be declared as 0, because malloc documents that it can either return 0 or a unique pointer on 0 size allocations. With glib this doesn't work anymore, because glib documents that for such allocation requests NULL is always returned which results in an error in our public API checks server-side. This patch complements the fix in the RPC layer by explicitly erroring out on the following combination of args used by our legacy APIs (their moder equivalents don't suffer from this): function(caller-allocated-array, size, ...) { if (!caller-allocated-array && size > 0) return error; } treating everything else as a valid input and potentially let that fail on the server-side rather than client-side. https://bugzilla.redhat.com/show_bug.cgi?id=1772842 Signed-off-by: Erik Skultety <eskultet@xxxxxxxxxx> Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> commit bf2988235cf09c407f39791d446b1ecb99be6c51 Author: Erik Skultety <eskultet@xxxxxxxxxx> Date: Mon Nov 18 10:30:20 2019 +0100 rpc: gendispatch: Fix a couple of places adding trailing spaces Signed-off-by: Erik Skultety <eskultet@xxxxxxxxxx> Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> commit 5e067ba4e16350272e6a9c33940b56cc6eb9dd9a Author: Ján Tomko <jtomko@xxxxxxxxxx> Date: Mon Nov 11 10:21:03 2019 +0100 conf: remove NULL check from virDomainQemuMonitorEventNew The qemu_domain_monitor_event_msg struct in qemu_protocol.x defines event as a nonnull_string and qemuMonitorJSONIOProcessEvent also errors out on a non-NULL event. Drop the check to fix the build with static analysis. This essentially reverts commit d343e8203d248635f5e7a0d86dd077f74d49e3af Signed-off-by: Ján Tomko <jtomko@xxxxxxxxxx> Reviewed-by: Michal Privoznik <mprivozn@xxxxxxxxxx> commit 7611a1ef002422c438c2e16fb2ce0d3034280253 Author: Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> Date: Tue Oct 22 12:13:41 2019 +0200 virt-aa-helper: testcase for shmem devices Adding build time self tests for basic (deprecated), doorbell and plain mode. Reviewed-by: Cole Robinson <crobinso@xxxxxxxxxx> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> commit 36afd1a78ed8e13e33cdf954c6618c178ef777a1 Author: Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> Date: Thu Oct 17 12:48:10 2019 +0200 virt-aa-helper: add rules for shmem devices Shared memory devices need qemu to be able to access certain paths either for the shared memory directly (mostly ivshmem-plain) or for a socket (mostly ivshmem-doorbell). Add logic to virt-aa-helper to render those apparmor rules based on the domain configuration. https://bugzilla.redhat.com/show_bug.cgi?id=1761645 Reviewed-by: Cole Robinson <crobinso@xxxxxxxxxx> Acked-by: Jamie Strandboge <jamie@xxxxxxxxxxxxx> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> commit d53f4d02d032ec14391b5052ec165105dfc338b5 Author: Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> Date: Wed Oct 16 09:35:27 2019 +0200 apparmor: let AppArmorSetSecurityImageLabel append rules There are currently broken use cases, e.g. snapshotting more than one disk at once like: $ virsh snapshot-create-as --domain eoan --disk-only --atomic --diskspec vda,snapshot=no --diskspec vdb,snapshot=no --diskspec vdc,file=/test/disk1.snapshot1.qcow,snapshot=external --diskspec vdd,file=/test/disk2.snapshot1.qcow,snapshot=external The command above will iterate from qemuDomainSnapshotCreateDiskActive and eventually add /test/disk1.snapshot1.qcow first (appears in the rules) to then later add /test/disk2.snapshot1.qcow and while doing so throwing away the former rule causing it to fail. All other calls to (re)load_profile already use append=true when adding rules append=false is only used when restoring rules [1]. Fix this by letting AppArmorSetSecurityImageLabel use append=true as well. Since this is removing a (unintentional) trigger to revoke all rules appended so far we agreed on review to do some tests, but in the tests no rules came back on: - hot-plug - hot-unplug - snapshotting Bugs: https://bugs.launchpad.net/libvirt/+bug/1845506 https://bugzilla.redhat.com/show_bug.cgi?id=1746684 [1]: https://bugs.launchpad.net/libvirt/+bug/1845506/comments/13 Reviewed-by: Cole Robinson <crobinso@xxxxxxxxxx> Acked-by: Jamie Strandboge <jamie@xxxxxxxxxxxxx> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> commit 9714f270f1e94a4b46a066a623b2cd239fa70faf Author: Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> Date: Wed Oct 16 09:32:52 2019 +0200 apparmor: refactor AppArmorSetSecurityImageLabel A lot of the code in AppArmorSetSecurityImageLabel is a duplicate of what is in reload_profile, this refactors AppArmorSetSecurityImageLabel to use reload_profile instead. Reviewed-by: Cole Robinson <crobinso@xxxxxxxxxx> Acked-by: Jamie Strandboge <jamie@xxxxxxxxxxxxx> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> commit 70cf0af7bf34b6c0f3c009efc8366767dcd3c27d Author: Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> Date: Wed Oct 16 09:15:14 2019 +0200 apparmor: drop useless call to get_profile_name reload_profile calls get_profile_name for no particular gain, lets remove that call. The string isn't used in that function later on and not registered/passed anywhere. It can only fail if it either can't allocate or if the virDomainDefPtr would have no uuid set (which isn't allowed). Thereby the only "check" it really provides is if it can allocate the string to then free it again. This was initially added in [1] when the code was still in AppArmorRestoreSecurityImageLabel (later moved) and even back then had no further effect than described above. [1]: https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/security/security_apparmor.c;h=16de0f26f41689e0c50481120d9f8a59ba1f4073;hb=bbaecd6a8f15345bc822ab4b79eb0955986bb2fd#l487 Reviewed-by: Cole Robinson <crobinso@xxxxxxxxxx> Acked-by: Jamie Strandboge <jamie@xxxxxxxxxxxxx> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> commit 9d38bce689557923c786ee4b36457830a167801c Author: Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> Date: Wed Oct 16 08:47:36 2019 +0200 virt-aa-helper: clarify command line options While only used internally from libvirt the options still are misleading enough to cause issues every now and then. Group modes, options and an adding extra file and extend the wording of the latter which had the biggest lack of clarity. Both add a file to the end of the rules, but one re-generates the rules from XML and the other keeps the existing rules as-is not considering the XML content. Reviewed-by: Cole Robinson <crobinso@xxxxxxxxxx> Acked-by: Jamie Strandboge <jamie@xxxxxxxxxxxxx> Signed-off-by: Christian Ehrhardt <christian.ehrhardt@xxxxxxxxxxxxx> _______________________________________________ osstest-output mailing list osstest-output@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/osstest-output
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |