From: osstest service owner <osstest-admin@xenproject.org>
To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org
Subject: [xen-unstable-smoke bisection] complete build-amd64
Date: Mon, 21 Dec 2020 20:07:11 +0000 [thread overview]
Message-ID: <E1krRSZ-0006jP-7i@osstest.test-lab.xenproject.org> (raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 9600 bytes --]
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@citrix.com>
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@cert.pl>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
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@citrix.com>
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@cert.pl>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
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
next reply other threads:[~2020-12-21 20:07 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-21 20:07 osstest service owner [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-11-28 17:02 [xen-unstable-smoke bisection] complete build-amd64 osstest service owner
2023-09-06 16:46 osstest service owner
2023-06-07 16:24 osstest service owner
2023-03-24 22:28 osstest service owner
2022-10-16 8:24 osstest service owner
2022-03-15 2:25 osstest service owner
2022-01-21 3:38 osstest service owner
2022-01-21 7:54 ` Jan Beulich
2021-08-16 23:23 osstest service owner
2021-07-10 0:19 osstest service owner
2021-07-06 17:29 osstest service owner
2021-02-24 16:57 osstest service owner
2021-02-10 19:10 osstest service owner
2021-01-28 18:38 osstest service owner
2020-11-10 23:25 osstest service owner
2020-10-23 23:30 osstest service owner
2020-10-07 18:40 osstest service owner
2020-04-25 8:57 osstest service owner
2019-05-15 8:13 osstest service owner
2019-04-13 5:09 osstest service owner
2019-04-13 15:51 ` Julien Grall
2019-04-13 15:53 ` Andrew Cooper
2019-01-02 21:14 osstest service owner
2018-11-12 23:38 osstest service owner
2018-09-25 21:39 osstest service owner
2018-04-07 6:19 osstest service owner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1krRSZ-0006jP-7i@osstest.test-lab.xenproject.org \
--to=osstest-admin@xenproject.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).