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

[xen-unstable-smoke bisection] complete build-amd64



branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64
testid xen-build

Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  d162f36848c4a98a782cc05820b0aa7ec1ae297d
  Bug not present: 6131dab5f2c8059a0fc7fd884bc6d4ff78ba44c2
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/157774/


  commit d162f36848c4a98a782cc05820b0aa7ec1ae297d
  Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Date:   Mon Sep 28 15:25:44 2020 +0100
  
      xen/x86: Fix memory leak in vcpu_create() error path
      
      Various paths in vcpu_create() end up calling 
paging_update_paging_modes(),
      which eventually allocate a monitor pagetable if one doesn't exist.
      
      However, an error in vcpu_create() results in the vcpu being cleaned up
      locally, and not put onto the domain's vcpu list.  Therefore, the monitor
      table is not freed by {hap,shadow}_teardown()'s loop.  This is caught by
      assertions later that we've successfully freed the entire hap/shadow 
memory
      pool.
      
      The per-vcpu loops in domain teardown logic is conceptually wrong, but 
exist
      due to insufficient existing structure in the existing logic.
      
      Break paging_vcpu_teardown() out of paging_teardown(), with mirrored 
breakouts
      in the hap/shadow code, and use it from arch_vcpu_create()'s error path.  
This
      fixes the memory leak.
      
      The new {hap,shadow}_vcpu_teardown() must be idempotent, and are written 
to be
      as tolerable as possible, with the minimum number of safety checks 
possible.
      In particular, drop the mfn_valid() check - if these fields are junk, 
then Xen
      is going to explode anyway.
      
      Reported-by: MichaÅ? LeszczyÅ?ski <michal.leszczynski@xxxxxxx>
      Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
      Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable-smoke/build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-unstable-smoke/build-amd64.xen-build 
--summary-out=tmp/157774.bisection-summary --basis-template=157696 
--blessings=real,real-bisect,real-retry xen-unstable-smoke build-amd64 xen-build
Searching for failure / basis pass:
 157761 fail [host=himrod1] / 157696 ok.
Failure / basis pass flights: 157761 / 157696
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
d162f36848c4a98a782cc05820b0aa7ec1ae297d
Basis pass 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
357db96a66e47e609c3b14768f1062e13eedbd93
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen-traditional.git#3d273dd05e51e5a1ffba3d98c7437ee84e8f8764-3d273dd05e51e5a1ffba3d98c7437ee84e8f8764
 
git://xenbits.xen.org/qemu-xen.git#7ea428895af2840d85c524f0bd11a38aac308308-7ea428895af2840d85c524f0bd11a38aac308308
 
git://xenbits.xen.org/xen.git#357db96a66e47e609c3b14768f1062e13eedbd93-d162f36848c4a98a782cc05820b0aa7ec1ae297d
Loaded 5001 nodes in revision graph
Searching for test results:
 157691 [host=himrod2]
 157692 [host=himrod2]
 157694 [host=himrod2]
 157695 pass irrelevant
 157697 fail irrelevant
 157698 pass irrelevant
 157699 pass irrelevant
 157700 pass irrelevant
 157701 pass irrelevant
 157702 pass irrelevant
 157703 fail irrelevant
 157704 pass irrelevant
 157706 fail irrelevant
 157696 pass 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
357db96a66e47e609c3b14768f1062e13eedbd93
 157707 pass irrelevant
 157761 fail 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
d162f36848c4a98a782cc05820b0aa7ec1ae297d
 157765 pass 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
357db96a66e47e609c3b14768f1062e13eedbd93
 157767 fail 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
d162f36848c4a98a782cc05820b0aa7ec1ae297d
 157768 pass 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
6131dab5f2c8059a0fc7fd884bc6d4ff78ba44c2
 157769 fail 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
d162f36848c4a98a782cc05820b0aa7ec1ae297d
 157770 pass 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
6131dab5f2c8059a0fc7fd884bc6d4ff78ba44c2
 157771 fail 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
d162f36848c4a98a782cc05820b0aa7ec1ae297d
 157773 pass 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
6131dab5f2c8059a0fc7fd884bc6d4ff78ba44c2
 157774 fail 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
d162f36848c4a98a782cc05820b0aa7ec1ae297d
Searching for interesting versions
 Result found: flight 157696 (pass), for basis pass
 For basis failure, parent search stopping at 
3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
6131dab5f2c8059a0fc7fd884bc6d4ff78ba44c2, results HASH(0x55feabd515e0) 
HASH(0x55feabd4ab20) HASH(0x55feabd56098) For basis failure, parent search 
stopping at 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
357db96a66e47e609c3b14768f1062e13eedbd93, results HASH(0x55feabd3f660) 
HASH(0x55feabd521e0) Result found: flight 157761 (fail), for \
 basis failure (at ancestor ~710)
 Repro found: flight 157765 (pass), for basis pass
 Repro found: flight 157767 (fail), for basis failure
 0 revisions at 3d273dd05e51e5a1ffba3d98c7437ee84e8f8764 
7ea428895af2840d85c524f0bd11a38aac308308 
6131dab5f2c8059a0fc7fd884bc6d4ff78ba44c2
No revisions left to test, checking graph state.
 Result found: flight 157768 (pass), for last pass
 Result found: flight 157769 (fail), for first failure
 Repro found: flight 157770 (pass), for last pass
 Repro found: flight 157771 (fail), for first failure
 Repro found: flight 157773 (pass), for last pass
 Repro found: flight 157774 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  d162f36848c4a98a782cc05820b0aa7ec1ae297d
  Bug not present: 6131dab5f2c8059a0fc7fd884bc6d4ff78ba44c2
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/157774/


  commit d162f36848c4a98a782cc05820b0aa7ec1ae297d
  Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Date:   Mon Sep 28 15:25:44 2020 +0100
  
      xen/x86: Fix memory leak in vcpu_create() error path
      
      Various paths in vcpu_create() end up calling 
paging_update_paging_modes(),
      which eventually allocate a monitor pagetable if one doesn't exist.
      
      However, an error in vcpu_create() results in the vcpu being cleaned up
      locally, and not put onto the domain's vcpu list.  Therefore, the monitor
      table is not freed by {hap,shadow}_teardown()'s loop.  This is caught by
      assertions later that we've successfully freed the entire hap/shadow 
memory
      pool.
      
      The per-vcpu loops in domain teardown logic is conceptually wrong, but 
exist
      due to insufficient existing structure in the existing logic.
      
      Break paging_vcpu_teardown() out of paging_teardown(), with mirrored 
breakouts
      in the hap/shadow code, and use it from arch_vcpu_create()'s error path.  
This
      fixes the memory leak.
      
      The new {hap,shadow}_vcpu_teardown() must be idempotent, and are written 
to be
      as tolerable as possible, with the minimum number of safety checks 
possible.
      In particular, drop the mfn_valid() check - if these fields are junk, 
then Xen
      is going to explode anyway.
      
      Reported-by: MichaÅ? LeszczyÅ?ski <michal.leszczynski@xxxxxxx>
      Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
      Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Revision graph left in 
/home/logs/results/bisect/xen-unstable-smoke/build-amd64.xen-build.{dot,ps,png,html,svg}.
----------------------------------------
157774: tolerable ALL FAIL

flight 157774 xen-unstable-smoke real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/157774/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-amd64                   6 xen-build               fail baseline untested


jobs:
 build-amd64                                                  fail    


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




 


Rackspace

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