From nobody Fri Oct 24 22:17:02 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.zohomail.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; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1519841260599387.9354535055196; Wed, 28 Feb 2018 10:07:40 -0800 (PST) Received: from localhost ([::1]:45942 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1er68h-0005Na-8K for importer@patchew.org; Wed, 28 Feb 2018 13:07:39 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41486) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1er66W-00044C-Sm for qemu-devel@nongnu.org; Wed, 28 Feb 2018 13:05:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1er66V-00042p-P7 for qemu-devel@nongnu.org; Wed, 28 Feb 2018 13:05:24 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:47014 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1er66P-0003zE-Ur; Wed, 28 Feb 2018 13:05:18 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6F771818535A; Wed, 28 Feb 2018 18:05:17 +0000 (UTC) Received: from localhost (unknown [10.40.205.159]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0EF9C2144B21; Wed, 28 Feb 2018 18:05:16 +0000 (UTC) From: Max Reitz To: qemu-block@nongnu.org Date: Wed, 28 Feb 2018 19:04:53 +0100 Message-Id: <20180228180507.3964-3-mreitz@redhat.com> In-Reply-To: <20180228180507.3964-1-mreitz@redhat.com> References: <20180228180507.3964-1-mreitz@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Wed, 28 Feb 2018 18:05:17 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Wed, 28 Feb 2018 18:05:17 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'mreitz@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PATCH v3 02/16] block: BDS deletion in bdrv_do_drained_begin() 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: Kevin Wolf , Fam Zheng , qemu-devel@nongnu.org, Max Reitz , Stefan Hajnoczi , John Snow 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" Draining a BDS (in the main loop) may cause it to go be deleted. That is rather suboptimal if we still plan to access it afterwards, so let us enclose the main body of the function with a bdrv_ref()/bdrv_unref() pair. Signed-off-by: Max Reitz Reviewed-by: Jeff Cody --- block/io.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/block/io.c b/block/io.c index ead12c4136..3b61e26114 100644 --- a/block/io.c +++ b/block/io.c @@ -294,12 +294,27 @@ void bdrv_do_drained_begin(BlockDriverState *bs, bool= recursive, BdrvChild *parent) { BdrvChild *child, *next; + bool in_main_loop =3D + qemu_get_current_aio_context() =3D=3D qemu_get_aio_context(); + /* bdrv_close() invokes bdrv_drain() with bs->refcnt =3D=3D 0; then, + * we may not invoke bdrv_ref()/bdrv_unref() because the latter + * would result in the refcount going back to 0, creating an + * infinite loop. + * Also, we have to be in the main loop because we may not call + * bdrv_unref() elsewhere. But because of that, the BDS is not in + * danger of going away without the bdrv_ref()/bdrv_unref() pair + * elsewhere, so we are fine then. */ + bool add_ref =3D in_main_loop && bs->refcnt > 0; =20 if (qemu_in_coroutine()) { bdrv_co_yield_to_drain(bs, true, recursive, parent); return; } =20 + if (add_ref) { + bdrv_ref(bs); + } + /* Stop things in parent-to-child order */ if (atomic_fetch_inc(&bs->quiesce_counter) =3D=3D 0) { aio_disable_external(bdrv_get_aio_context(bs)); @@ -315,6 +330,10 @@ void bdrv_do_drained_begin(BlockDriverState *bs, bool = recursive, bdrv_do_drained_begin(child->bs, true, child); } } + + if (add_ref) { + bdrv_unref(bs); + } } =20 void bdrv_drained_begin(BlockDriverState *bs) --=20 2.14.3