From nobody Wed Nov 27 04:38:09 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1701800451; cv=none; d=zohomail.com; s=zohoarc; b=JOK8pmQd5akQHg4x/FrEyU5wDSbZxpVrVUFVJsdPsgLPiCB9U1QKhrXAF+W5AbS/2LUcbipO4OnpC6LZZ5pvEZL69YQ0jRZjPKxagnkW8pgBKpaq+pbqVMBIuxmlgGGth4EYxIqi2RZqnhbODTekWYXNs82R4VNbJMGTLVCAx9Q= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1701800451; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=2xkZi3XPrXCgy6FPT4RsS2T7UTaP09qNkYfhhg0EmAc=; b=Nev2EI7X9GYPtiU2PMSVsfNSWm4ZKXdbfx8pN+Og9ShVVHrua3OAEWZ5/BScMLGEaVVkjl7tR6pgz5edFKVBEGs7TVCE3a81qNt/vdGYmVJmQtmUBYhmAfxsN9CDESdP94GwQ3VZA0c5YuAybimlzFTvoU2ikSyLrRRBXqC6Kt8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1701800451826938.114420055655; Tue, 5 Dec 2023 10:20:51 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.648186.1012304 (Exim 4.92) (envelope-from ) id 1rAa26-0003Ts-W2; Tue, 05 Dec 2023 18:20:34 +0000 Received: by outflank-mailman (output) from mailman id 648186.1012304; Tue, 05 Dec 2023 18:20:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rAa26-0003SQ-O4; Tue, 05 Dec 2023 18:20:34 +0000 Received: by outflank-mailman (input) for mailman id 648186; Tue, 05 Dec 2023 18:20:33 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rAa25-0002fT-Ls for xen-devel@lists.xenproject.org; Tue, 05 Dec 2023 18:20:33 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f9c4140d-939a-11ee-98e5-6d05b1d4d9a1; Tue, 05 Dec 2023 19:20:33 +0100 (CET) Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-551--Te_eBzINpij5dm8ZX6ilA-1; Tue, 05 Dec 2023 13:20:28 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id CCAF2386A0AF; Tue, 5 Dec 2023 18:20:26 +0000 (UTC) Received: from localhost (unknown [10.39.194.111]) by smtp.corp.redhat.com (Postfix) with ESMTP id AFE9A3C25; Tue, 5 Dec 2023 18:20:25 +0000 (UTC) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: f9c4140d-939a-11ee-98e5-6d05b1d4d9a1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701800431; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2xkZi3XPrXCgy6FPT4RsS2T7UTaP09qNkYfhhg0EmAc=; b=Ku+Yxukh1G++AZSyP02JQQxBVn8GBn/4scck2VsAmUe2U9uSZqmeY6obnyyaOXYYfVRsKk du6+uuBJxnixlsSOeB1Wp+jjwrlIi9xJesxliFZg/gA+FqLHLwObG01yZ9ZPnMECcX87Fm KZbM2fbp0pBqIngxPPj2GFEYuWlCA08= X-MC-Unique: -Te_eBzINpij5dm8ZX6ilA-1 From: Stefan Hajnoczi To: qemu-devel@nongnu.org Cc: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Stefan Hajnoczi , Vladimir Sementsov-Ogievskiy , Cleber Rosa , Xie Changlong , Paul Durrant , Ari Sundholm , Jason Wang , Eric Blake , John Snow , Eduardo Habkost , Wen Congyang , Alberto Garcia , Anthony Perard , "Michael S. Tsirkin" , Stefano Stabellini , qemu-block@nongnu.org, Juan Quintela , Paolo Bonzini , Kevin Wolf , Coiby Xu , Fabiano Rosas , Hanna Reitz , Zhang Chen , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Pavel Dovgalyuk , Peter Xu , Emanuele Giuseppe Esposito , Fam Zheng , Leonardo Bras , David Hildenbrand , Li Zhijian , xen-devel@lists.xenproject.org Subject: [PATCH v2 04/14] aio: make aio_context_acquire()/aio_context_release() a no-op Date: Tue, 5 Dec 2023 13:20:01 -0500 Message-ID: <20231205182011.1976568-5-stefanha@redhat.com> In-Reply-To: <20231205182011.1976568-1-stefanha@redhat.com> References: <20231205182011.1976568-1-stefanha@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1701800452345100003 Content-Type: text/plain; charset="utf-8" aio_context_acquire()/aio_context_release() has been replaced by fine-grained locking to protect state shared by multiple threads. The AioContext lock still plays the role of balancing locking in AIO_WAIT_WHILE() and many functions in QEMU either require that the AioContext lock is held or not held for this reason. In other words, the AioContext lock is purely there for consistency with itself and serves no real purpose anymore. Stop actually acquiring/releasing the lock in aio_context_acquire()/aio_context_release() so that subsequent patches can remove callers across the codebase incrementally. I have performed "make check" and qemu-iotests stress tests across x86-64, ppc64le, and aarch64 to confirm that there are no failures as a result of eliminating the lock. Signed-off-by: Stefan Hajnoczi Reviewed-by: Eric Blake Acked-by: Kevin Wolf --- util/async.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/util/async.c b/util/async.c index 8f90ddc304..04ee83d220 100644 --- a/util/async.c +++ b/util/async.c @@ -725,12 +725,12 @@ void aio_context_unref(AioContext *ctx) =20 void aio_context_acquire(AioContext *ctx) { - qemu_rec_mutex_lock(&ctx->lock); + /* TODO remove this function */ } =20 void aio_context_release(AioContext *ctx) { - qemu_rec_mutex_unlock(&ctx->lock); + /* TODO remove this function */ } =20 QEMU_DEFINE_STATIC_CO_TLS(AioContext *, my_aiocontext) --=20 2.43.0