Re: [PATCH 0/4] xen: domain-tracked allocations, and fault injection

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.