From nobody Thu May 2 05:30:19 2024 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 148948997783648.78913266421921; Tue, 14 Mar 2017 04:12:57 -0700 (PDT) Received: from localhost ([::1]:57797 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cnkNr-0005xE-KN for importer@patchew.org; Tue, 14 Mar 2017 07:12:55 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47988) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cnkN7-0005sJ-Rf for qemu-devel@nongnu.org; Tue, 14 Mar 2017 07:12:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cnkN2-0005e5-0h for qemu-devel@nongnu.org; Tue, 14 Mar 2017 07:12:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45632) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cnkMz-0005au-8K; Tue, 14 Mar 2017 07:12:01 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6CAC681226; Tue, 14 Mar 2017 11:12:01 +0000 (UTC) Received: from donizetti.redhat.com (ovpn-117-149.ams2.redhat.com [10.36.117.149]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v2EBBvig016903; Tue, 14 Mar 2017 07:11:59 -0400 From: Paolo Bonzini To: qemu-devel@nongnu.org Date: Tue, 14 Mar 2017 12:11:57 +0100 Message-Id: <20170314111157.14464-2-pbonzini@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 14 Mar 2017 11:12:01 +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] [PATCH] block: quiesce AioContext when detaching from it 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: Halil Pasic , qemu-block@nongnu.org, Stefan Hajnoczi , Max Reitz 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" While it is true that bdrv_set_aio_context only works on a single BlockDriverState subtree (see commit message for 53ec73e, "block: Use bdrv_drain to replace uncessary bdrv_drain_all", 2015-07-07), it works at the AioContext level rather than the BlockDriverState level. Therefore, it is also necessary to trigger pending bottom halves too, even if no requests are pending. For NBD this ensures that the aio_co_schedule of a previous call to nbd_attach_aio_context is completed before detaching from the old AioContext; it fixes qemu-iotest 094. Another similar bug happens when the VM is stopped and the virtio-blk dataplane irqfd is torn down. In this case it's possible that guest I/O gets stuck if notify_guest_bh was scheduled but doesn't run. Calling aio_poll from another AioContext is safe if non-blocking; races such as the one mentioned in the commit message for c9d1a56 ("block: only call aio_poll on the current thread's AioContext", 2016-10-28) are a concern for blocking calls. I considered other options, including: - moving the bs->wakeup mechanism to AioContext, and letting the caller check. This might work for virtio which has a clear place to wakeup (notify_place_bh) and check the condition (virtio_blk_data_plane_stop). For aio_co_schedule I couldn't find a clear place to check the condition. - adding a dummy oneshot bottom half and waiting for it to trigger. This has the complication that bottom half list is LIFO for historical reasons. There were performance issues caused by bottom half ordering in the past, so I decided against it for 2.9. Fixes: 99723548561978da8ef44cf804fb7912698f5d88 Reported-by: Max Reitz Reported-by: Halil Pasic Tested-by: Halil Pasic Signed-off-by: Paolo Bonzini Reviewed-by: Eric Blake --- block.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/block.c b/block.c index f293ccb..e159251 100644 --- a/block.c +++ b/block.c @@ -4272,8 +4272,15 @@ void bdrv_attach_aio_context(BlockDriverState *bs, =20 void bdrv_set_aio_context(BlockDriverState *bs, AioContext *new_context) { + AioContext *ctx; + bdrv_drain(bs); /* ensure there are no in-flight requests */ =20 + ctx =3D bdrv_get_aio_context(bs); + while (aio_poll(ctx, false)) { + /* wait for all bottom halves to execute */ + } + bdrv_detach_aio_context(bs); =20 /* This function executes in the old AioContext so acquire the new one= in --=20 2.9.3