From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53009) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBrjQ-0006Pq-VA for qemu-devel@nongnu.org; Wed, 23 Dec 2015 17:18:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBrjP-0002wx-Qq for qemu-devel@nongnu.org; Wed, 23 Dec 2015 17:18:04 -0500 References: <1450867706-19860-2-git-send-email-pbonzini@redhat.com> <567B12B6.7030308@redhat.com> <2122516119.2111109.1450907702054.JavaMail.zimbra@redhat.com> From: Max Reitz Message-ID: <567B1D92.5080907@redhat.com> Date: Wed, 23 Dec 2015 23:17:54 +0100 MIME-Version: 1.0 In-Reply-To: <2122516119.2111109.1450907702054.JavaMail.zimbra@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GGeTkBuvO1R0NEAwqUecnhwAf6tes1j1v" Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] block: use drained section in bdrv_close List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GGeTkBuvO1R0NEAwqUecnhwAf6tes1j1v Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23.12.2015 22:55, Paolo Bonzini wrote: >=20 >> On 23.12.2015 11:48, Paolo Bonzini wrote: >>> bdrv_close is used when ejecting a medium. >> >> Is it still? Other than it maybe being indirectly called through >> bdrv_delete(), it shouldn't be. >=20 > Yes, through blk_remove_bs -> bdrv_unref -> bdrv_delete. OK, I was asking because bdrv_close() was invoked directly by the ejection code until recently and thought that maybe you were referring to that, and that there might have been a way for I/O to spill to the new medium if one issued a change command. >>> Use a drained section to = ensure >>> that all I/O goes to either the old medium or the bitbucket. >> >> Since the BDS will be deleted after bdrv_close() has been called, wher= e >> else would the I/O go now? >=20 > The ioeventfd could be processed during bs->drv->bdrv_close. For > example I/O could be submitted while qcow2_close's qcow2_cache_flush > yields, and the result would probably be corrupted metadata. Ah, OK, so you meant =E2=80=9CEither all or no I/O should go to the mediu= m=E2=80=9D, I thought it was about the fact that I/O might go somewhere else than the old medium or /dev/null (e.g. the new medium in case of a change). That makes more sense now, thanks! :-) Applied to my block tree: https://github.com/XanClic/qemu/commits/block Max >=20 > Paolo >=20 >> Max >> >>> Signed-off-by: Paolo Bonzini >>> --- >>> block.c | 4 +++- >>> 1 file changed, 3 insertions(+), 1 deletion(-) >>> >>> diff --git a/block.c b/block.c >>> index 411edbf..01655de 100644 >>> --- a/block.c >>> +++ b/block.c >>> @@ -2154,9 +2154,10 @@ void bdrv_close(BlockDriverState *bs) >>> bdrv_io_limits_disable(bs); >>> } >>> =20 >>> - bdrv_drain(bs); /* complete I/O */ >>> + bdrv_drained_begin(bs); /* complete I/O */ >>> bdrv_flush(bs); >>> bdrv_drain(bs); /* in case flush left pending I/O */ >>> + >>> notifier_list_notify(&bs->close_notifiers, bs); >>> =20 >>> if (bs->blk) { >>> @@ -2206,6 +2207,7 @@ void bdrv_close(BlockDriverState *bs) >>> g_free(ban); >>> } >>> QLIST_INIT(&bs->aio_notifiers); >>> + bdrv_drained_end(bs); >>> } >>> =20 >>> void bdrv_close_all(void) >>> >> >> >> --GGeTkBuvO1R0NEAwqUecnhwAf6tes1j1v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWex2SAAoJEDuxQgLoOKyt1rMIAImmJ5YEvtxWqR8ChgkUL59n eeveDU1VaVB9EKJp/m2sndI2URNhcC+RNpmjrYUfjPnAajKF/fhveW/qw7IUZ8r5 MLEqR5pyRQsUH11wOLhNAKmYHd1ydkfO0KyMeaLWxBa0uGhjsEO7Y7aPyv8+6ykg at3ycU6z0CZvnQnTBJEQzez6OTGxRTkbYYExNtiquT8ass5Kyw9NgTr56Z4pyCh/ /bIUDAEblQf1QockWyII5s25fctXzfcHGAprs5QUKlcAmaGD/thmI6C2LxaQ31DA DJFXG7+nw0TFPQTGZw0yEgHoEFjV9q0RDY+XPdigi9fDaasrqJ7kjMUZpm4Cixs= =zBp8 -----END PGP SIGNATURE----- --GGeTkBuvO1R0NEAwqUecnhwAf6tes1j1v--