[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 0/4] xen: domain-tracked allocations, and fault injection
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.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |