From nobody Mon Sep 16 19:18:35 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; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1541216601052686.396716717105; Fri, 2 Nov 2018 20:43:21 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 070FA31256A9; Sat, 3 Nov 2018 03:43:19 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C54E360BEC; Sat, 3 Nov 2018 03:43:18 +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 76EDA180BAD1; Sat, 3 Nov 2018 03:43:18 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id wA33EYuc011608 for ; Fri, 2 Nov 2018 23:14:34 -0400 Received: by smtp.corp.redhat.com (Postfix) id BA09E5D760; Sat, 3 Nov 2018 03:14:34 +0000 (UTC) Received: from cv1.lan (ovpn-124-15.rdu2.redhat.com [10.10.124.15]) by smtp.corp.redhat.com (Postfix) with ESMTP id 01EC45D6A9; Sat, 3 Nov 2018 03:14:33 +0000 (UTC) From: Chris Venteicher To: libvir-list@redhat.com Date: Fri, 2 Nov 2018 22:13:28 -0500 Message-Id: <20181103031338.11600-28-cventeic@redhat.com> In-Reply-To: <20181103031338.11600-1-cventeic@redhat.com> References: <20181103031338.11600-1-cventeic@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-loop: libvir-list@redhat.com Cc: walling@linux.ibm.com, Chris Venteicher , david@redhat.com Subject: [libvirt] [PATCH v4 27/37] qemu_process: Stop locking QMP process monitor immediately 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: , MIME-Version: 1.0 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.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Sat, 03 Nov 2018 03:43:19 +0000 (UTC) Content-Type: text/plain; charset="utf-8" Locking the monitor object immediately after call to qemuMonitorOpen doesn't make sense now that we have expanded the QEMU process code to cover more than the original capabilities usecase. Removing the monitor lock makes the qemuConnectMonitorQmp code consistent with the qemuConnectMonitor code used to establish the monitor when QEMU process is started for domains. Signed-off-by: Chris Venteicher --- src/qemu/qemu_process.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 08522a1580..6bd3da97ca 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -8297,8 +8297,6 @@ qemuConnectMonitorQmp(qemuProcessPtr proc) =20 VIR_STEAL_PTR(proc->mon, mon); =20 - virObjectLock(proc->mon); - /* Exit capabilities negotiation mode and enter QEMU command mode * by issuing qmp_capabilities command to QEMU */ if (qemuMonitorSetCapabilities(proc->mon) < 0) { --=20 2.17.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list