From nobody Sun Feb 8 20:48:39 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) client-ip=170.10.129.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=fail(p=none dis=none) header.from=gmail.com Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.zohomail.com with SMTPS id 1655061430220721.9025756961667; Sun, 12 Jun 2022 12:17:10 -0700 (PDT) Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-551-tAjlvOZ7OSepQlwPabloNQ-1; Sun, 12 Jun 2022 15:17:03 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 084E929ABA01; Sun, 12 Jun 2022 19:17:01 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id D52F12026D64; Sun, 12 Jun 2022 19:16:56 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 787E4194705D; Sun, 12 Jun 2022 19:16:56 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 16462194705B for ; Sun, 12 Jun 2022 19:16:55 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 054692166B29; Sun, 12 Jun 2022 19:16:55 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast07.extmail.prod.ext.rdu2.redhat.com [10.11.55.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 011E52166B26 for ; Sun, 12 Jun 2022 19:16:54 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D9C1B3C02B84 for ; Sun, 12 Jun 2022 19:16:54 +0000 (UTC) Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-613-p-Hh3WAhMv24aoaAnbBHSA-1; Sun, 12 Jun 2022 15:16:53 -0400 Received: by mail-qt1-f176.google.com with SMTP id x16so2661119qtw.12 for ; Sun, 12 Jun 2022 12:16:52 -0700 (PDT) Received: from andromeda.markmielke.com ([2607:fea8:c25f:8500::845b]) by smtp.gmail.com with ESMTPSA id ed12-20020a05620a490c00b006a67eb4610fsm4290481qkb.116.2022.06.12.12.16.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Jun 2022 12:16:51 -0700 (PDT) X-MC-Unique: tAjlvOZ7OSepQlwPabloNQ-1 X-Original-To: libvir-list@listman.corp.redhat.com X-MC-Unique: p-Hh3WAhMv24aoaAnbBHSA-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=+I0XSN/dMlBFFvxyvJUPK2N4PUpgxxoZrqqatPxZP24=; b=UTGBQxp8lz6lZ0FxBsTNzoM5ov+54daDjapbg+8XhL+GrNfUvc9dXrRbOL7EjKkwTM ZMuhD8HBbsZQqFQckR/sqLwFPE0Ye6fCpNa3t5YpRo/JrDnUmOBnP/GGV1CPvZnZrMJ8 DA8NRVrTHGMbeACQt5mgQ4keSVsFzUSRTBa5H2kvXLMwZxhZ2Qypz99QR7Mb9XiJOYoX T8qX+C/XYDh5zwLWUKmKxiAnRQ61zYsqlK7ZA6GiZkLxjwhZMVnHo4h4vEaqb7i8IoGl vsbb9tbIZVx/uzRxqFNmB1UiQlojhir3R8mKE3eow6ZezSSHvIfWoKizh1k0atgIAHYA K8/Q== X-Gm-Message-State: AOAM530s1WHPlLDCH96IkJufTDRQ/vAinX9IF/2xYn3wsmMJkCAHfVoj G2wjoLd8XuNRwHf9pJog3Y1Xx/cR6d0= X-Google-Smtp-Source: ABdhPJy+DHIL1kJZoiJrppLeHd1cNuMeDw+tDJmpt0g0D+h5aNpe5uN0YVgb9R5xC8JHYZ3Je6H/1g== X-Received: by 2002:a05:622a:1911:b0:304:e171:83bc with SMTP id w17-20020a05622a191100b00304e17183bcmr38265712qtc.222.1655061412143; Sun, 12 Jun 2022 12:16:52 -0700 (PDT) From: Mark Mielke To: libvir-list@redhat.com Subject: [libvirt PATCH] Fix incorrect uses of g_clear_pointer() introduced in 8.1.0 Date: Sun, 12 Jun 2022 15:16:50 -0400 Message-Id: <20220612191650.292526-1-mark.mielke@gmail.com> MIME-Version: 1.0 X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Mimecast-Bulk-Signature: yes X-Mimecast-Spam-Signature: bulk X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Mielke Errors-To: libvir-list-bounces@redhat.com Sender: "libvir-list" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=libvir-list-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZM-MESSAGEID: 1655061431979100001 Content-Type: text/plain; charset="utf-8"; x-default="true" This is a partial revert of 87a43a907f0ad4897a28ad7c216bc70f37270b93. 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. 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 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. Reviewed-by: J=C3=A1n Tomko --- src/qemu/qemu_agent.c | 3 ++- src/qemu/qemu_monitor.c | 3 ++- src/util/vireventglib.c | 12 ++++++++---- 3 files changed, 12 insertions(+), 6 deletions(-) diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c index f57a8d5f25..e6e92c7dc4 100644 --- a/src/qemu/qemu_agent.c +++ b/src/qemu/qemu_agent.c @@ -452,8 +452,9 @@ static void qemuAgentUnregister(qemuAgent *agent) { if (agent->watch) { + g_source_destroy(agent->watch); vir_g_source_unref(agent->watch, agent->context); - g_clear_pointer(&agent->watch, g_source_destroy); + agent->watch =3D NULL; } } =20 diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index 37bcbde31e..32c993a941 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -794,8 +794,9 @@ void qemuMonitorUnregister(qemuMonitor *mon) { if (mon->watch) { + g_source_destroy(mon->watch); vir_g_source_unref(mon->watch, mon->context); - g_clear_pointer(&mon->watch, g_source_destroy); + mon->watch =3D NULL; } } =20 diff --git a/src/util/vireventglib.c b/src/util/vireventglib.c index fc04d8f712..983787932f 100644 --- a/src/util/vireventglib.c +++ b/src/util/vireventglib.c @@ -228,7 +228,8 @@ virEventGLibHandleUpdate(int watch, =20 VIR_DEBUG("Removed old handle source=3D%p", data->source); g_source_destroy(data->source); - g_clear_pointer(&data->source, g_source_destroy); + vir_g_source_unref(data->source, NULL); + data->source =3D NULL; data->events =3D 0; } =20 @@ -275,8 +276,9 @@ virEventGLibHandleRemove(int watch) data, watch, data->fd); =20 if (data->source !=3D NULL) { + g_source_destroy(data->source); vir_g_source_unref(data->source, NULL); - g_clear_pointer(&data->source, g_source_destroy); + data->source =3D NULL; data->events =3D 0; } =20 @@ -417,8 +419,9 @@ virEventGLibTimeoutUpdate(int timer, if (data->source =3D=3D NULL) goto cleanup; =20 + g_source_destroy(data->source); vir_g_source_unref(data->source, NULL); - g_clear_pointer(&data->source, g_source_destroy); + data->source =3D NULL; } =20 cleanup: @@ -465,8 +468,9 @@ virEventGLibTimeoutRemove(int timer) data, timer); =20 if (data->source !=3D NULL) { + g_source_destroy(data->source); vir_g_source_unref(data->source, NULL); - g_clear_pointer(&data->source, g_source_destroy); + data->source =3D NULL; } =20 /* since the actual timeout deletion is done asynchronously, a timeout= Update call may --=20 2.36.1