From: Stefano Stabellini <sstabellini@kernel.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
"Jan Beulich" <JBeulich@suse.com>,
"Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Julien Grall" <julien@xen.org>,
"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
"Tamas K Lengyel" <tamas@tklengyel.com>
Subject: Re: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
Date: Thu, 7 Jan 2021 17:49:53 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.21.2101071630480.7075@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <20201223163442.8840-1-andrew.cooper3@citrix.com>
On Wed, 23 Dec 2020, Andrew Cooper wrote:
> This was not the christmas hacking project that I was planning to do, but it
> has had some exciting results.
>
> After some discussion on an earlier thread, Tamas has successfully got fuzzing
> of Xen working via kfx, and this series is a prototype for providing better
> testing infrastructure.
>
> And to prove a point, this series has already found a memory leak in ARM's
> dom0less smoke test.
>
> >From https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/929518792
>
> (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input)
> (XEN) Freed 328kB init memory.
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER4
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER8
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER12
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER16
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER20
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER24
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER28
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER32
> (XEN) d0v0: vGICD: unhandled word write 0x000000ffffffff to ICACTIVER0
> (XEN) physdev.c:16:d0v0 PHYSDEVOP cmd=25: not implemented
> (XEN) physdev.c:16:d0v0 PHYSDEVOP cmd=15: not implemented
> (XEN) physdev.c:16:d0v0 PHYSDEVOP cmd=15: not implemented
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) d1 has 2 outstanding heap allocations
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
> For some reason, neither of the evtchn default memory allocations are freed,
> but it's not clear why d1 shut down to being with. Stefano - any ideas?
Right, this is confusing. It is not hard to believe that memory leaks
exist on the dom0less shutdown path because dom0less domains are not
really shutdown today. I imagine there could be issues.
But I don't understand why _domain_destroy gets called in the first
place for d1. Maybe a domain_create failure leads to goto fail and
_domain_destroy(). I wanted to run a test but ran out of time.
next prev parent reply other threads:[~2021-01-08 1:50 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-23 16:34 [PATCH 0/4] xen: domain-tracked allocations, and fault injection Andrew Cooper
2020-12-23 16:34 ` [PATCH 1/4] xen/dmalloc: Introduce dmalloc() APIs Andrew Cooper
2021-01-05 15:56 ` Jan Beulich
2021-01-13 23:16 ` Andrew Cooper
2021-01-14 10:14 ` Jan Beulich
2021-01-14 15:30 ` Andrew Cooper
2021-01-05 16:01 ` Jan Beulich
2022-12-11 17:24 ` Julien Grall
2020-12-23 16:34 ` [PATCH 2/4] xen/evtchn: Switch to dmalloc Andrew Cooper
2021-01-05 16:09 ` Jan Beulich
2020-12-23 16:34 ` [PATCH 3/4] xen/domctl: Introduce fault_ttl Andrew Cooper
2021-01-05 16:39 ` Jan Beulich
2021-01-13 23:58 ` Andrew Cooper
2020-12-23 16:34 ` [PATCH 4/4] tools/misc: Test for fault injection Andrew Cooper
2020-12-23 16:41 ` Jan Beulich
2021-01-08 1:49 ` Stefano Stabellini [this message]
2022-12-11 17:21 ` [PATCH 0/4] xen: domain-tracked allocations, and " Julien Grall
[not found] <160874604800.15699.17952392608790984041@600e7e483b3a>
2020-12-23 19:45 ` Stefano Stabellini
2020-12-23 20:01 ` Andrew Cooper
2020-12-23 20:10 ` Stefano Stabellini
2021-01-04 9:11 ` Zheng, Fam
2021-01-04 9:38 ` Roger Pau Monné
2021-01-04 10:53 ` Zheng, Fam
2021-01-04 17:30 ` Stefano Stabellini
2021-01-04 17:35 ` Julien Grall
2021-01-04 17:36 ` Andrew Cooper
2021-01-04 18:11 ` Stefano Stabellini
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=alpine.DEB.2.21.2101071630480.7075@sstabellini-ThinkPad-T480s \
--to=sstabellini@kernel.org \
--cc=JBeulich@suse.com \
--cc=Volodymyr_Babchuk@epam.com \
--cc=andrew.cooper3@citrix.com \
--cc=julien@xen.org \
--cc=roger.pau@citrix.com \
--cc=tamas@tklengyel.com \
--cc=wl@xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.