[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [xen-unstable test] 16014: regressions - FAIL



flight 16014 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/16014/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2 14 guest-localmigrate/x10 fail REGR. vs. 
15643-bisect
 test-amd64-i386-xl-multivcpu 14 guest-localmigrate/x10 fail REGR. vs. 
16012-bisect

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv           14 guest-localmigrate/x10      fail pass in 15817
 test-amd64-i386-xl           14 guest-localmigrate/x10      fail pass in 15817
 test-amd64-amd64-pv      14 guest-localmigrate/x10 fail in 15817 pass in 16014
 test-amd64-i386-xend-winxpsp3 12 guest-localmigrate/x10 fail in 15817 pass in 
16014
 test-amd64-i386-xend-qemut-winxpsp3 9 guest-localmigrate fail in 15817 pass in 
16014
 test-amd64-i386-qemut-win     7 windows-install    fail in 15817 pass in 16014
 test-amd64-i386-qemut-win-vcpus1 7 windows-install fail in 15817 pass in 16014
 test-amd64-amd64-qemut-win    7 windows-install    fail in 15817 pass in 16014
 test-amd64-amd64-win          7 windows-install    fail in 15817 pass in 16014

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 15442
 test-amd64-amd64-xl-qemut-win  7 windows-install              fail  like 15442

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop         fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check        fail never pass
 test-amd64-i386-xl-qemut-win-vcpus1 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-qemut-win    16 leak-check/check             fail   never pass
 test-amd64-i386-qemut-win-vcpus1 16 leak-check/check           fail never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-qemut-win   16 leak-check/check             fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop              fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  fd997a96d448
baseline version:
 xen                  6c1b12c884b4

------------------------------------------------------------
People who touched revisions under test:
  David Scott <dave.scott@xxxxxxxxxxxxx>
  Ian Campbell <ian.campbell@xxxxxxxxxx>
  Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Keir Fraser <keir@xxxxxxx>
  Matthew Daley <mattjd@xxxxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           fail    
 test-amd64-i386-rhel6hvm-amd                                 pass    
 test-amd64-i386-qemut-rhel6hvm-amd                           pass    
 test-amd64-i386-qemuu-rhel6hvm-amd                           pass    
 test-amd64-amd64-xl-qemut-win7-amd64                         fail    
 test-amd64-i386-xl-qemut-win7-amd64                          fail    
 test-amd64-amd64-xl-qemuu-win7-amd64                         fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               pass    
 test-amd64-i386-qemut-rhel6hvm-intel                         pass    
 test-amd64-i386-qemuu-rhel6hvm-intel                         pass    
 test-amd64-i386-xl-multivcpu                                 fail    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           fail    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-qemut-win-vcpus1                             fail    
 test-amd64-i386-xl-qemut-win-vcpus1                          fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1                     fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-amd64-amd64-qemut-win                                   fail    
 test-amd64-i386-qemut-win                                    fail    
 test-amd64-amd64-xl-qemut-win                                fail    
 test-amd64-amd64-xl-win                                      fail    
 test-amd64-i386-xend-qemut-winxpsp3                          fail    
 test-amd64-amd64-xl-qemut-winxpsp3                           fail    
 test-amd64-amd64-xl-qemuu-winxpsp3                           fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    


------------------------------------------------------------
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.

------------------------------------------------------------
changeset:   26523:fd997a96d448
tag:         tip
user:        Jan Beulich <jbeulich@xxxxxxxx>
date:        Fri Feb 08 11:06:04 2013 +0100
    
    x86: debugging code for testing 16Tb support on smaller memory systems
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Keir Fraser <keir@xxxxxxx>
    
    
changeset:   26522:ffd30e7388ad
user:        Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
date:        Thu Feb 07 14:21:47 2013 +0000
    
    oxenstored: Enforce a maximum message size of 4096 bytes
    
    The maximum size of a message is part of the protocol spec in
      xen/include/public/io/xs_wire.h
    
    Before this patch a client which sends an overly large message can
    cause a buffer read overrun.
    
    Note if a badly-behaved client sends a very large message
    then it will be difficult for them to make their connection
    work again-- they will probably need to reboot.
    
    Signed-off-by: David Scott <dave.scott@xxxxxxxxxxxxx>
    Acked-by: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
    Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    
    
changeset:   26521:2c0fd406f02c
user:        Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
date:        Thu Feb 07 14:21:44 2013 +0000
    
    tools/ocaml: oxenstored: Be more paranoid about ring reading
    
    oxenstored makes use of the OCaml Xenbus bindings, in which the
    function xs_ring_read in tools/ocaml/libs/xb/xs_ring_stubs.c is used
    to read from the shared memory Xenstore ring.
    
    This function does not correctly handle all possible (prod, cons)
    states when MASK_XENSTORE_IDX(prod) > MASK_XENSTORE_IDX(cons).
    
    The root cause is the use of the unmasked values of prod and cons to
    calculate to_read.  If prod is set to an out-of-range value, the ring
    peer can cause to_read to be too large or even negative.  This allows
    the ring peer to force oxenstored to read and write out of range for
    the buffers leading to a crash or possibly to privilege escalation.
    
    Correct this by masking the values of cons and prod at the start, so
    we only deal with masked values.  This makes the logic simpler, as
    semantically inappropriate values of the upper bits of the ring
    pointers are simply ignored.
    
    The same vulnerability does not exist in the ring writer because the
    only use made of the unmasked value is the check which prevents the
    prod pointer overtaking the cons pointer.  A ring peer which defeats
    this check will suffer only lost data.
    
    
    However, additionally, precautions need to be taken to ensure that
    req_cons and req_prod are only read once in each function.  Without
    the use of volatile or some asm construct, the compiler can "prove"
    that req_cons and req_prod do not change unexpectedly and is permitted
    to "amplify" the read of (say) req_cons into two reads at different
    times, giving two different values for use as cons, and then use the
    two sources of cons interchangeably.  (The use of xen_mb() does not
    forbid this.)
    
    Therefore do the reads of req_cons and req_prod through a volatile
    pointer in both xs_ring_read and xs_ring_write.
    
    This is currently believed to be a theoretical vulnerability as we are
    not aware of any compilers which amplify reads in this way.
    
    
    This is a security issue, part of XSA-38 / CVE-2013-0215.
    
    
    Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Tested-by: Matthew Daley <mattjd@xxxxxxxxx>
    Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    
    
changeset:   26520:6c1b12c884b4
user:        Ian Campbell <Ian.Campbell@xxxxxxxxxx>
date:        Tue Feb 05 15:47:41 2013 +0000
    
    xen: enable stubdom on a per arch basis
    
    ... and disable on ARM (for now).
    
    Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
    Committed-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
    
    
========================================
commit 2a1354d655d816feaad7dbdb8364f40a208439c1
Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
Date:   Thu Jan 17 15:52:16 2013 +0000

    e1000: fix compile warning introduced by security fix, and debugging
    
    e33f918c19e393900b95a2bb6b10668dfe96a8f2, the fix for XSA-41,
    and its cherry picks in 4.2 and 4.1 introduced this compiler warning:
      hw/e1000.c:641: warning: 'return' with a value, in function returning void
    
    In upstream qemu (where this change came from), e1000_receive returns
    a value used by queueing machinery to decide whether to try
    resubmitting the packet later.  Returning "size" means that the packet
    has been dealt with and should not be retried.
    
    In this old branch (aka qemu-xen-traditional), this machinery is
    absent and e1000_receive returns void.  Fix the return statement.
    
    Also add a debugging statement along the lines of the others in this
    function.
    
    Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.