Re: [libvirt PATCH] Fix incorrect uses of g_clear_pointer() introduced in 8.1.0

On a Sunday in 2022, Mark Mielke wrote: >This is a partial revert of 87a43a907f0ad4897a28ad7c216bc70f37270b93. I'll drop the trailing period before pushing. > >The change to use g_clear_pointer() in more places was accidentally >applied to cases involving vir_g_source_unref(). > >In some cases, the ordering of g_source_destroy() and >vir_g_source_unref() was reversed, which resulted in the source being >marked as destroyed, after it is already unreferenced. Oops, sorry I missed that during review. >This >use-after-free case might work in many cases, but with versions of >glibc older than 2.64.0 it may defer unref to run within the main s/glibc/glib/ >thread to avoid a race condition, which creates a large distance >between the g_source_unref() and g_source_destroy(). > >In some cases, the call to vir_g_source_unref() was replaced with a >second call to g_source_destroy(), leading to a memory leak or worse. > >In our experience, the symptoms were that use of libvirt-python became >slower over time, with OpenStack nova-compute initially taking around >one second to periodically query the host PCI devices, and within an >hour it was taking over a minute to complete the same operation, until >it is was eventually running this query back-to-back, resulting in the >nova-compute process consuming 100% of one CPU thread, losing its >RabbitMQ connection frequently, and showing up as down to the control >plane. Your patch is missing a sign-off https://libvirt.org/hacking.html#developer-certificate-of-origin Just replying to this e-mail with the Signed-off-by line is enough - no need to resend the patch. I'll push it with the sign-off included after the pipeline succeds: https://gitlab.com/janotomko/libvirt/-/pipelines/562139546 >--- > src/qemu/qemu_agent.c | 3 ++- > src/qemu/qemu_monitor.c | 3 ++- > src/util/vireventglib.c | 12 ++++++++---- > 3 files changed, 12 insertions(+), 6 deletions(-) > Reviewed-by: Ján Tomko <jtomko(a)redhat.com&gt; Jano