When attempting to use portio_list_destroy() to remove a portio_list then the
QEMU process segfaults with the backtrace below:

    #0 0x5555599a34b6 in phys_section_destroy ../softmmu/physmem.c:996
    #1 0x5555599a37a3 in phys_sections_free ../softmmu/physmem.c:1011
    #2 0x5555599b24aa in address_space_dispatch_free ../softmmu/physmem.c:2430
    #3 0x55555996a283 in flatview_destroy ../softmmu/memory.c:292
    #4 0x55555a2cb9fb in call_rcu_thread ../util/rcu.c:284
    #5 0x55555a29b71d in qemu_thread_start ../util/qemu-thread-posix.c:541
    #6 0x7ffff4a0cea6 in start_thread nptl/pthread_create.c:477
    #7 0x7ffff492ca2e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xfca2e)

The problem is that portio_list_destroy() unparents the portio_list MemoryRegions
causing them to be freed immediately, however the flatview still has a reference to the
MemoryRegion which causes a use-after-free segfault when the RCU thread next updates
the flatview.

This series resolves the issue by QOMifying the MemoryRegionPortioList, and setting
that as the MemoryRegion owner instead of the portio_list owner. This allows the
MemoryRegionPortioList to hold the refcount for its MemoryRegion and so manually
finalize it when flatview_destroy() removes its final refcount.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>


Mark Cave-Ayland (3):
  softmmu/ioport.c: allocate MemoryRegionPortioList ports on the heap
  softmmu/ioport.c: QOMify MemoryRegionPortioList
  softmmu/ioport.c: make MemoryRegionPortioList owner of portio_list
    MemoryRegions

 softmmu/ioport.c | 62 ++++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 55 insertions(+), 7 deletions(-)

-- 
2.30.2