From nobody Wed Dec 17 05:39:21 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1498235368960786.8876939299565; Fri, 23 Jun 2017 09:29:28 -0700 (PDT) Received: from localhost ([::1]:36252 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dORSY-0007sy-41 for importer@patchew.org; Fri, 23 Jun 2017 12:29:26 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59200) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dORLe-0000VB-4c for qemu-devel@nongnu.org; Fri, 23 Jun 2017 12:22:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dORLa-0007TE-1I for qemu-devel@nongnu.org; Fri, 23 Jun 2017 12:22:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36632) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dORLX-0007RL-NH; Fri, 23 Jun 2017 12:22:11 -0400 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 BD8277D4E0; Fri, 23 Jun 2017 16:22:10 +0000 (UTC) Received: from noname.redhat.com (ovpn-117-196.ams2.redhat.com [10.36.117.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id D6DB67E8ED; Fri, 23 Jun 2017 16:22:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BD8277D4E0 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=kwolf@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com BD8277D4E0 From: Kevin Wolf To: qemu-block@nongnu.org Date: Fri, 23 Jun 2017 18:21:04 +0200 Message-Id: <1498234919-27316-7-git-send-email-kwolf@redhat.com> In-Reply-To: <1498234919-27316-1-git-send-email-kwolf@redhat.com> References: <1498234919-27316-1-git-send-email-kwolf@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.28]); Fri, 23 Jun 2017 16:22:10 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 06/61] migration: avoid recursive AioContext locking in save_vmstate() X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kwolf@redhat.com, qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Stefan Hajnoczi AioContext was designed to allow nested acquire/release calls. It uses a recursive mutex so callers don't need to worry about nesting...or so we thought. BDRV_POLL_WHILE() is used to wait for block I/O requests. It releases the AioContext temporarily around aio_poll(). This gives IOThreads a chance to acquire the AioContext to process I/O completions. It turns out that recursive locking and BDRV_POLL_WHILE() don't mix. BDRV_POLL_WHILE() only releases the AioContext once, so the IOThread will not be able to acquire the AioContext if it was acquired multiple times. Instead of trying to release AioContext n times in BDRV_POLL_WHILE(), this patch simply avoids nested locking in save_vmstate(). It's the simplest fix and we should step back to consider the big picture with all the recent changes to block layer threading. This patch is the final fix to solve 'savevm' hanging with -object iothread. Signed-off-by: Stefan Hajnoczi Reviewed-by: Eric Blake Reviewed-by: Paolo Bonzini Signed-off-by: Kevin Wolf --- migration/savevm.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/migration/savevm.c b/migration/savevm.c index 6bfd489..5846d9c 100644 --- a/migration/savevm.c +++ b/migration/savevm.c @@ -2144,6 +2144,14 @@ int save_snapshot(const char *name, Error **errp) goto the_end; } =20 + /* The bdrv_all_create_snapshot() call that follows acquires the AioCo= ntext + * for itself. BDRV_POLL_WHILE() does not support nested locking beca= use + * it only releases the lock once. Therefore synchronous I/O will dea= dlock + * unless we release the AioContext before bdrv_all_create_snapshot(). + */ + aio_context_release(aio_context); + aio_context =3D NULL; + ret =3D bdrv_all_create_snapshot(sn, bs, vm_state_size, &bs); if (ret < 0) { error_setg(errp, "Error while creating snapshot on '%s'", @@ -2154,7 +2162,9 @@ int save_snapshot(const char *name, Error **errp) ret =3D 0; =20 the_end: - aio_context_release(aio_context); + if (aio_context) { + aio_context_release(aio_context); + } if (saved_vm_running) { vm_start(); } --=20 1.8.3.1