On Tue, 27 Aug 2024 at 09:37, David Hildenbrand <da...@redhat.com> wrote: > > As reported by Peter, we might be leaking memory when removing the > highest RAMBlock (in the weird ram_addr_t space), and adding a new one. > > We will fail to realize that we already allocated bitmaps for more > dirty memory blocks, and effectively discard the pointers to them. > > Fix it by getting rid of last_ram_page() and simply storing the number > of dirty memory blocks that have been allocated. We'll store the number > of blocks along with the actual pointer to keep it simple. > > Looks like this leak was introduced as we switched from using a single > bitmap_zero_extend() to allocating multiple bitmaps: > bitmap_zero_extend() relies on g_renew() which should have taken care of > this. > > Resolves: > https://lkml.kernel.org/r/CAFEAcA-k7a+VObGAfCFNygQNfCKL=AfX6A4kScq=vssk0pe...@mail.gmail.com > Reported-by: Peter Maydell <peter.mayd...@linaro.org> > Fixes: 5b82b703b69a ("memory: RCU ram_list.dirty_memory[] for safe RAM > hotplug") > Cc: qemu-sta...@nongnu.org > Cc: Stefan Hajnoczi <stefa...@redhat.com> > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: Peter Xu <pet...@redhat.com> > Cc: "Philippe Mathieu-Daudé" <phi...@linaro.org> > Signed-off-by: David Hildenbrand <da...@redhat.com>
I checked, and with this fix (plus various others I've sent out last week) we can run "make check" for the x86_64-softmmu target under asan/lsan without getting any leak reports. So (at least to that extent) Tested-by: Peter Maydell <peter.mayd...@linaro.org> -- PMM
