From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48312) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bxgzK-0007bE-RY for qemu-devel@nongnu.org; Fri, 21 Oct 2016 17:04:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bxgzJ-0005ju-Mq for qemu-devel@nongnu.org; Fri, 21 Oct 2016 17:04:26 -0400 References: <1475237406-26917-1-git-send-email-famz@redhat.com> <1475237406-26917-4-git-send-email-famz@redhat.com> From: Max Reitz Message-ID: <36e4e4a0-b679-3b71-baf4-7513a38c594e@redhat.com> Date: Fri, 21 Oct 2016 23:04:13 +0200 MIME-Version: 1.0 In-Reply-To: <1475237406-26917-4-git-send-email-famz@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qm9xDq9QRFFEkVisT81HcCf9W0VwjImWO" Subject: Re: [Qemu-devel] [PATCH v8 03/36] block: Introduce image file locking List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , qemu-devel@nongnu.org Cc: berrange@redhat.com, John Snow , qemu-block@nongnu.org, Kevin Wolf , rjones@redhat.com, Jeff Cody , Markus Armbruster , stefanha@redhat.com, den@openvz.org, pbonzini@redhat.com, eblake@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qm9xDq9QRFFEkVisT81HcCf9W0VwjImWO From: Max Reitz To: Fam Zheng , qemu-devel@nongnu.org Cc: berrange@redhat.com, John Snow , qemu-block@nongnu.org, Kevin Wolf , rjones@redhat.com, Jeff Cody , Markus Armbruster , stefanha@redhat.com, den@openvz.org, pbonzini@redhat.com, eblake@redhat.com Message-ID: <36e4e4a0-b679-3b71-baf4-7513a38c594e@redhat.com> Subject: Re: [PATCH v8 03/36] block: Introduce image file locking References: <1475237406-26917-1-git-send-email-famz@redhat.com> <1475237406-26917-4-git-send-email-famz@redhat.com> In-Reply-To: <1475237406-26917-4-git-send-email-famz@redhat.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable On 30.09.2016 14:09, Fam Zheng wrote: > Block drivers can implement this new operation .bdrv_lockf to actually = lock the > image in the protocol specific way. >=20 > Signed-off-by: Fam Zheng > --- > block.c | 52 +++++++++++++++++++++++++++++++++++++++= ++++++++ > include/block/block.h | 4 +++- > include/block/block_int.h | 5 +++++ > include/hw/block/block.h | 2 ++ > 4 files changed, 62 insertions(+), 1 deletion(-) >=20 > diff --git a/block.c b/block.c > index 493ecf3..9d600df 100644 > --- a/block.c > +++ b/block.c > @@ -235,6 +235,7 @@ BlockDriverState *bdrv_new(void) > notifier_with_return_list_init(&bs->before_write_notifiers); > bs->refcnt =3D 1; > bs->aio_context =3D qemu_get_aio_context(); > + bs->cur_lock =3D IMAGE_LOCK_MODE__MAX; (Yes, I know, I'm supposed to write a high-level review, but...) I don't really like using values for enums that are not actually supposed to be part of the enum. Maybe nolock would be a reasonable choic= e? > qemu_co_queue_init(&bs->flush_queue); > =20 > @@ -925,6 +926,48 @@ out: > g_free(gen_node_name); > } > =20 > +ImageLockMode bdrv_lock_mode_from_flags(int flags) > +{ > + if (flags & BDRV_O_NO_LOCK) { > + return IMAGE_LOCK_MODE_NOLOCK; > + } else if (flags & BDRV_O_SHARED_LOCK) { > + return IMAGE_LOCK_MODE_SHARED; > + } else if (flags & BDRV_O_EXCLUSIVE_LOCK) { > + return IMAGE_LOCK_MODE_EXCLUSIVE; > + } else { > + return IMAGE_LOCK_MODE_AUTO; > + } > +} I don't know if there's been any discussion about the order of the flags here, but I personally would order them exactly the other way around: Asking for exclusive locking should override nolock, in my opinion. > + > +ImageLockMode bdrv_get_lock_mode(BlockDriverState *bs) > +{ > + return bs->cur_lock; > +} > + > +int bdrv_set_lock_mode(BlockDriverState *bs, ImageLockMode mode) > +{ > + int ret; > + > + if (bs->cur_lock =3D=3D mode) { > + return 0; > + } else if (!bs->drv) { > + return -ENOMEDIUM; > + } else if (!bs->drv->bdrv_lockf) { > + if (bs->file) { > + return bdrv_set_lock_mode(bs->file->bs, mode); > + } > + return 0; > + } > + ret =3D bs->drv->bdrv_lockf(bs, mode); > + if (ret =3D=3D -ENOTSUP) { > + /* Handle it the same way as !bs->drv->bdrv_lockf */ > + ret =3D 0; Yes, well, why do you handle both as success? Wouldn't returning -ENOTSUP make more sense? I guess the caller can find out itself by checking whether bs->cur_lock has changed, but... > + } else if (ret =3D=3D 0) { > + bs->cur_lock =3D mode; > + } > + return ret; > +} > + > static QemuOptsList bdrv_runtime_opts =3D { > .name =3D "bdrv_common", > .head =3D QTAILQ_HEAD_INITIALIZER(bdrv_runtime_opts.head), > @@ -1076,6 +1119,10 @@ static int bdrv_open_common(BlockDriverState *bs= , BdrvChild *file, > goto free_and_fail; > } > =20 > + if (open_flags & BDRV_O_INACTIVE) { > + open_flags =3D (open_flags & ~BDRV_O_LOCK_MASK) & BDRV_O_NO_LO= CK; I suppose the second & is supposed to be a |? > + } > + > ret =3D refresh_total_sectors(bs, bs->total_sectors); > if (ret < 0) { > error_setg_errno(errp, -ret, "Could not refresh total sector c= ount"); > @@ -2273,6 +2320,7 @@ static void bdrv_close(BlockDriverState *bs) > if (bs->drv) { > BdrvChild *child, *next; > =20 > + bdrv_set_lock_mode(bs, IMAGE_LOCK_MODE_NOLOCK); > bs->drv->bdrv_close(bs); > bs->drv =3D NULL; > =20 > @@ -3188,6 +3236,9 @@ void bdrv_invalidate_cache(BlockDriverState *bs, = Error **errp) This function's name is pretty weird... Maybe it would be better to rename it to "bdrv_complete_incoming" or something. (Unrelated to this series, of course.) > error_setg_errno(errp, -ret, "Could not refresh total sector c= ount"); > return; > } > + if (bs->cur_lock !=3D IMAGE_LOCK_MODE__MAX) { > + bdrv_set_lock_mode(bs, bs->cur_lock); > + } > } > =20 > void bdrv_invalidate_cache_all(Error **errp) > @@ -3230,6 +3281,7 @@ static int bdrv_inactivate_recurse(BlockDriverSta= te *bs, > } > =20 > if (setting_flag) { > + ret =3D bdrv_set_lock_mode(bs, IMAGE_LOCK_MODE_NOLOCK); Maybe it would make sense to do something with the return value...? :-) At least you should probably check whether bdrv_get_lock_mode(bs) =3D=3D IMAGE_LOCK_MODE_NOLOCK. Max > bs->open_flags |=3D BDRV_O_INACTIVE; > } > return 0; --qm9xDq9QRFFEkVisT81HcCf9W0VwjImWO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEvBAEBCAAZBQJYCoLNEhxtcmVpdHpAcmVkaGF0LmNvbQAKCRD0B9sAYdXPQEiR CAC45e4rb7vWalylmPQPv9CmAAMj8IH9UBDE9wI4aDOPSc7AEr7BfGR6I2VLPM6P YAtuI/GiJibMtYwJzVc6hwc8vjriJfJ7WSFBz9zUzdQjs+RntBZNwJKmZUHvMi5G k4lSIDCzAIjJXvLOCM8bAk9Oxvzg76W0SEEpK8vAuK9bXCdIY3uzHbzFX+9oT/yx YTmH2SWjqcYaoa76KiEge0/xrNa2CtwrshuH9ZZBxWELeQDdikmA2gB186enGmA2 5Qqsb1nuPv0f06ILPxitUF2jZFYz5/EGI58YSLkS1GZebPnKS8vSWQkvcBfXMltL yi+VUjPPmNMYuyEUoG+Cv0/X =tkPD -----END PGP SIGNATURE----- --qm9xDq9QRFFEkVisT81HcCf9W0VwjImWO--