From nobody Mon Apr 29 00:22:44 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1558342840; cv=none; d=zoho.com; s=zohoarc; b=WXWSPs8MSutjgO9lowzdege3b6vdVMC0TsMARGa4R13cAmueUsbSsU3RxSXB8pwyEu8rNyOFuaGQNy2VQCyuSE1hl75s+pOdPjf58PlOnYhiyC02R1+KhpiPBTmLzTQIV9XnqGxaBf3sl6BOb1i94mcTIzS4CLehdSIGnnhXM0I= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1558342840; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To:ARC-Authentication-Results; bh=KRThpR2yhlofZUiGZX2hxa5oW7i4IJzquulPjKriSxw=; b=heD1xayByHXOoCZbjzx9Fo7Fsdg7cn1w0/zaRnMFIJntWjL7d+sFp8lMuaixtWM+B7WNN4+YEzqkGK09O9sHgkiF/rE9EnrmmNaOIkxiSPbULfAh7oYmSlarqpyV8LKTzT3wabefx8DSxrFBTeFwey5UyTjFhAwo7Tt+4HSwsm4= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1558342840196305.47578438865753; Mon, 20 May 2019 02:00:40 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 45726309175F; Mon, 20 May 2019 09:00:27 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8CB235D967; Mon, 20 May 2019 09:00:23 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 696FEE161; Mon, 20 May 2019 09:00:10 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x4IAOxMr024590 for ; Sat, 18 May 2019 06:24:59 -0400 Received: by smtp.corp.redhat.com (Postfix) id D0DA66178F; Sat, 18 May 2019 10:24:59 +0000 (UTC) Received: from mx1.redhat.com (ext-mx20.extmail.prod.ext.phx2.redhat.com [10.5.110.49]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CBE015F9BA for ; Sat, 18 May 2019 10:24:57 +0000 (UTC) Received: from huawei.com (szxga04-in.huawei.com [45.249.212.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0D267308624C for ; Sat, 18 May 2019 10:24:56 +0000 (UTC) Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 615D7CDEB4FF2D7EE985 for ; Sat, 18 May 2019 18:24:53 +0800 (CST) Received: from localhost (10.177.17.7) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.439.0; Sat, 18 May 2019 18:24:44 +0800 From: Wang King To: Date: Sat, 18 May 2019 18:24:36 +0800 Message-ID: <20190518102436.5028-1-king.wang@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.177.17.7] X-CFilter-Loop: Reflected X-Greylist: Sender passed SPF test, Sender IP whitelisted by DNSRBL, ACL 216 matched, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Sat, 18 May 2019 10:24:56 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Sat, 18 May 2019 10:24:56 +0000 (UTC) for IP:'45.249.212.190' DOMAIN:'szxga04-in.huawei.com' HELO:'huawei.com' FROM:'king.wang@huawei.com' RCPT:'' X-RedHat-Spam-Score: -0.702 (RCVD_IN_DNSWL_LOW, SPF_HELO_PASS, SPF_PASS) 45.249.212.190 szxga04-in.huawei.com 45.249.212.190 szxga04-in.huawei.com X-Scanned-By: MIMEDefang 2.84 on 10.5.110.49 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-loop: libvir-list@redhat.com X-Mailman-Approved-At: Mon, 20 May 2019 05:00:09 -0400 Cc: wengdingzhong@huawei.com, weidong.huang@huawei.com, jianjay.zhou@huawei.com Subject: [libvirt] [PATCH] qemuProcessReconnect: ensure vm xml integrity when save status X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Mon, 20 May 2019 09:00:35 +0000 (UTC) Content-Type: text/plain; charset="utf-8" From: Dingzhong Weng libvirtd starts qemuProcessReconnect threads when libvirtd is starting and there are live vm on the host. but as qemuProcessReconnect threads are simply side job done by libvirtd upon start and are only called for existing vm. these threads are not managed like that of worker threads and event pool. once libvirtd receives SIGTERM signal or any similar command right after it starts, these qemuProcessReconnect threads might still be running and libvirtd goes to clean up and frees qemu_driver and its components. In this short window, qemuProcessReconnect threads might have a NULL qemu_driver->xmlopt.format, skip this function, and only partial vm status can be saved to disk. As a result, vm may fail to recover with missing information. this patch increases qemu_driver->xmlopt ref count during the lifecycle of qemuProcessReconnect so that libvirtd will not release this resource until qemuProcessReconnect threads finish using it. thus make sure all of vm status information can be formatted and thus maintain its integrity in virDomainSaveStatus. no vm is killed in this patch. Signed-off-by: Dingzhong Weng --- src/qemu/qemu_process.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 90466771cd..36b9b5fd03 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -8000,6 +8000,7 @@ qemuProcessReconnect(void *opaque) struct qemuProcessReconnectData *data =3D opaque; virQEMUDriverPtr driver =3D data->driver; virDomainObjPtr obj =3D data->obj; + virDomainXMLOptionPtr xmlopt =3D NULL; qemuDomainObjPrivatePtr priv; qemuDomainJobObj oldjob; int state; @@ -8023,6 +8024,9 @@ qemuProcessReconnect(void *opaque) cfg =3D virQEMUDriverGetConfig(driver); priv =3D obj->privateData; =20 + /* need xmlopt later to save status, do not free */ + xmlopt =3D virObjectRef(driver->xmlopt); + if (!(caps =3D virQEMUDriverGetCapabilities(driver, false))) goto error; =20 @@ -8218,7 +8222,7 @@ qemuProcessReconnect(void *opaque) } =20 /* update domain state XML with possibly updated state in virDomainObj= */ - if (virDomainSaveStatus(driver->xmlopt, cfg->stateDir, obj, driver->ca= ps) < 0) + if (virDomainSaveStatus(xmlopt, cfg->stateDir, obj, driver->caps) < 0) goto error; =20 /* Run an hook to allow admins to do some magic */ @@ -8253,6 +8257,7 @@ qemuProcessReconnect(void *opaque) virDomainObjEndAPI(&obj); virObjectUnref(cfg); virObjectUnref(caps); + virObjectUnref(xmlopt); virNWFilterUnlockFilterUpdates(); virIdentitySetCurrent(NULL); return; --=20 2.18.0.windows.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list