From nobody Wed Nov 27 04:54:07 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 ARC-Seal: i=1; a=rsa-sha256; t=1558708661; cv=none; d=zoho.com; s=zohoarc; b=AQETbNRL/5AKmbYENCecB1msn+4EQEMHCDTkhX3Ur3Zllq/KoirV9FeDZ1e1M/PIVhgaHCmAK3VTe0VVEBL6BkN18C+1QIVLEIHAUkb1/C2POrmmVgFv34sXi6Pzp5lvkRaTNWnjfIMimGJag7xVo5e1plcBIIGZ8TxHa64oJO8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1558708661; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To:ARC-Authentication-Results; bh=vIskQvrioZCX+JgzmVM3OlW7YFFqjPeoNoqdOA96ejw=; b=aPArYedkOU6DloFT08yOLHjdqvspzStsc+7FNvkDUtkTiR8FlSgE7XvcpHX7bxHO8NJ7P0ocaeSbDYbGXrPWv0oW5p8dFwdsz80mjlCVg80hbYMVjThBp0IDZMg8hBb5MR60s1+U2OphLzijxzOx3ar0b2ECVDRp4OtTkuEbTAU= 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; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1558708661199708.0581669250117; Fri, 24 May 2019 07:37:41 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D8E277E425; Fri, 24 May 2019 14:37:33 +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 627CB10027C4; Fri, 24 May 2019 14:37:31 +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 24EAC1806B0F; Fri, 24 May 2019 14:37:28 +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 x4OEZx7M011307 for ; Fri, 24 May 2019 10:35:59 -0400 Received: by smtp.corp.redhat.com (Postfix) id CB38469287; Fri, 24 May 2019 14:35:59 +0000 (UTC) Received: from moe.brq.redhat.com (unknown [10.43.2.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 53D4217243 for ; Fri, 24 May 2019 14:35:59 +0000 (UTC) From: Michal Privoznik To: libvir-list@redhat.com Date: Fri, 24 May 2019 16:35:38 +0200 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v1 02/11] virStoragePoolObjListForEach: Grab a reference for pool object 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.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 24 May 2019 14:37:39 +0000 (UTC) Content-Type: text/plain; charset="utf-8" Turns out there's one callback that might remove a storage pool during its run: storagePoolUpdateAllState() call storagePoolUpdateStateCallback() which may call virStoragePoolUpdateInactive() which in turn may call virStoragePoolObjRemove(). Problem is that the UpdateStateCallback() sees a storage pool object with just two references: one for each hash table holding the object. If the function ends up calling ObjRemove() then upon removing the object from hash tables those references are gone and thus any subsequent call touching the object is invalid. The solution to this problem is to grab reference for the object we are running iterator with. Signed-off-by: Michal Privoznik Reviewed-by: J=C3=A1n Tomko --- src/conf/virstorageobj.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/conf/virstorageobj.c b/src/conf/virstorageobj.c index 6af4a1a22d..286f55fb0c 100644 --- a/src/conf/virstorageobj.c +++ b/src/conf/virstorageobj.c @@ -411,9 +411,13 @@ virStoragePoolObjListForEachCb(void *payload, virStoragePoolObjPtr obj =3D payload; struct _virStoragePoolObjListForEachData *data =3D opaque; =20 + /* Grab a reference so that we don't rely only on references grabbed by + * hash table earlier. Remember, an iterator can remove object from the + * hash table. */ + virObjectRef(obj); virObjectLock(obj); data->iter(obj, data->opaque); - virObjectUnlock(obj); + virStoragePoolObjEndAPI(&obj); =20 return 0; } --=20 2.21.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list