From: Fam Zheng <famz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>,
Jeff Cody <jcody@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Eric Blake <eblake@redhat.com>,
qemu-block@nongnu.org, rjones@redhat.com, stefanha@redhat.com,
pbonzini@redhat.com, John Snow <jsnow@redhat.com>,
berrange@redhat.com, den@openvz.org
Subject: Re: [Qemu-devel] [PATCH v6 04/22] block: Introduce image file locking
Date: Wed, 22 Jun 2016 15:23:28 +0800 [thread overview]
Message-ID: <20160622072328.GD22636@ad.usersys.redhat.com> (raw)
In-Reply-To: <20160617113435.GF5431@noname.redhat.com>
On Fri, 06/17 13:34, Kevin Wolf wrote:
> Am 03.06.2016 um 10:48 hat Fam Zheng geschrieben:
> > Block drivers can implement this new operation .bdrv_lockf to actually lock the
> > image in the protocol specific way.
> >
> > Signed-off-by: Fam Zheng <famz@redhat.com>
> > ---
> > block.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++
> > include/block/block.h | 11 ++++++++-
> > include/block/block_int.h | 5 +++++
> > 3 files changed, 72 insertions(+), 1 deletion(-)
> >
> > diff --git a/block.c b/block.c
> > index 736432f..4c2a3ff 100644
> > --- a/block.c
> > +++ b/block.c
> > @@ -854,6 +854,50 @@ out:
> > g_free(gen_node_name);
> > }
> >
> > +BdrvLockfCmd bdrv_get_locking_cmd(int flags)
> > +{
> > + if (flags & BDRV_O_NO_LOCK) {
> > + return BDRV_LOCKF_UNLOCK;
> > + } else if (flags & BDRV_O_SHARED_LOCK) {
> > + return BDRV_LOCKF_SHARED;
> > + } else if (flags & BDRV_O_RDWR) {
> > + return BDRV_LOCKF_EXCLUSIVE;
> > + } else {
> > + return BDRV_LOCKF_SHARED;
> > + }
> > +}
>
> It feels a bit counterintuitive to use the very same operation for
> "start of critical section, but don't actually lock" and "end of
> critical section".
>
> Is there a specific reason why you chose this instead of separate
> .bdrv_lock/bdrv_unlock callbacks?
Because unlike open(2)/close(2), locking and unlocking are typically
implemented with one parameterized operation (fcntl(2)) underneath, I followed
that naturally.
>
> > +static int bdrv_lock_unlock_image_do(BlockDriverState *bs, BdrvLockfCmd cmd)
> > +{
> > + int ret;
> > +
> > + if (bs->cur_lock == cmd) {
> > + return 0;
> > + } else if (!bs->drv) {
> > + return -ENOMEDIUM;
> > + } else if (!bs->drv->bdrv_lockf) {
> > + return 0;
> > + }
> > + ret = bs->drv->bdrv_lockf(bs, cmd);
> > + if (ret == -ENOTSUP) {
> > + /* Handle it the same way as !bs->drv->bdrv_lockf */
> > + ret = 0;
> > + } else if (ret == 0) {
> > + bs->cur_lock = cmd;
> > + }
> > + return ret;
> > +}
>
> Okay, so the callback is supposed to support going from exclusive to
> shared and vice versa? Noted for the next patches.
Yes.
>
> > +static int bdrv_lock_image(BlockDriverState *bs)
> > +{
> > + return bdrv_lock_unlock_image_do(bs, bdrv_get_locking_cmd(bs->open_flags));
> > +}
> > +
> > +static int bdrv_unlock_image(BlockDriverState *bs)
> > +{
> > + return bdrv_lock_unlock_image_do(bs, BDRV_LOCKF_UNLOCK);
> > +}
> > +
> > static QemuOptsList bdrv_runtime_opts = {
> > .name = "bdrv_common",
> > .head = QTAILQ_HEAD_INITIALIZER(bdrv_runtime_opts.head),
> > @@ -1003,6 +1047,14 @@ static int bdrv_open_common(BlockDriverState *bs, BdrvChild *file,
> > goto free_and_fail;
> > }
> >
> > + if (!(open_flags & (BDRV_O_NO_LOCK | BDRV_O_INACTIVE))) {
> > + ret = bdrv_lock_image(bs);
> > + if (ret) {
> > + error_setg(errp, "Failed to lock image");
> > + goto free_and_fail;
> > + }
> > + }
> > +
> > ret = refresh_total_sectors(bs, bs->total_sectors);
> > if (ret < 0) {
> > error_setg_errno(errp, -ret, "Could not refresh total sector count");
> > @@ -2164,6 +2216,7 @@ static void bdrv_close(BlockDriverState *bs)
> > if (bs->drv) {
> > BdrvChild *child, *next;
> >
> > + bdrv_unlock_image(bs);
> > bs->drv->bdrv_close(bs);
> > bs->drv = NULL;
> >
> > @@ -3187,6 +3240,9 @@ void bdrv_invalidate_cache(BlockDriverState *bs, Error **errp)
> > error_setg_errno(errp, -ret, "Could not refresh total sector count");
> > return;
> > }
> > + if (!(bs->open_flags & BDRV_O_NO_LOCK)) {
> > + bdrv_lock_image(bs);
> > + }
> > }
>
> I think the if is unnecessary, bdrv_lock_image() already looks at
> BDRV_O_NO_LOCK.
I intentionally made enum BDRV_O_LOCK_* start from non-zero, so bdrv_lock_image
will call drv->bdrv_lockf even for BDRV_O_NO_LOCK. In the case of
lock-mode=off, I think we should skip that.
>
> > void bdrv_invalidate_cache_all(Error **errp)
> > @@ -3229,6 +3285,7 @@ static int bdrv_inactivate_recurse(BlockDriverState *bs,
> > }
> >
> > if (setting_flag) {
> > + ret = bdrv_unlock_image(bs);
> > bs->open_flags |= BDRV_O_INACTIVE;
> > }
> > return 0;
>
> Kevin
Fam
next prev parent reply other threads:[~2016-06-22 7:23 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-03 8:48 [Qemu-devel] [PATCH v6 00/22] block: Lock images when opening Fam Zheng
2016-06-03 8:48 ` [Qemu-devel] [PATCH v6 01/22] block: Add flag bits for image locking Fam Zheng
2016-06-17 9:05 ` Kevin Wolf
2016-06-03 8:48 ` [Qemu-devel] [PATCH v6 02/22] qapi: Add lock-mode in blockdev-add options Fam Zheng
2016-06-17 9:17 ` Kevin Wolf
2016-06-18 11:16 ` Fam Zheng
2016-06-20 13:24 ` Kevin Wolf
2016-06-03 8:48 ` [Qemu-devel] [PATCH v6 03/22] blockdev: Add and parse "lock-mode" option for image locking Fam Zheng
2016-06-17 9:23 ` Kevin Wolf
2016-07-05 13:37 ` [Qemu-devel] [Qemu-block] " Kevin Wolf
2016-07-08 2:56 ` Fam Zheng
2016-07-08 9:50 ` Kevin Wolf
2016-07-08 13:05 ` Max Reitz
2016-09-06 16:45 ` Kevin Wolf
2016-09-06 16:51 ` Daniel P. Berrange
2016-09-06 17:15 ` Kevin Wolf
2016-06-03 8:48 ` [Qemu-devel] [PATCH v6 04/22] block: Introduce image file locking Fam Zheng
2016-06-08 1:51 ` Jason Dillaman
2016-06-08 2:45 ` Fam Zheng
2016-06-17 11:34 ` Kevin Wolf
2016-06-22 7:23 ` Fam Zheng [this message]
2016-06-22 8:30 ` Kevin Wolf
2016-06-22 9:04 ` Fam Zheng
2016-06-03 8:48 ` [Qemu-devel] [PATCH v6 05/22] osdep: Add qemu_lock_fd and qemu_unlock_fd Fam Zheng
2016-06-17 12:12 ` Kevin Wolf
2016-06-22 7:34 ` Fam Zheng
2016-06-22 8:34 ` Kevin Wolf
2016-06-22 9:10 ` Fam Zheng
2016-06-03 8:49 ` [Qemu-devel] [PATCH v6 06/22] osdep: Introduce qemu_dup Fam Zheng
2016-06-17 12:32 ` Kevin Wolf
2016-06-17 13:08 ` [Qemu-devel] [Qemu-block] " Kevin Wolf
2016-06-22 7:37 ` Fam Zheng
2016-06-03 8:49 ` [Qemu-devel] [PATCH v6 07/22] raw-posix: Use qemu_dup Fam Zheng
2016-06-03 8:49 ` [Qemu-devel] [PATCH v6 08/22] raw-posix: Add image locking support Fam Zheng
2016-06-03 23:53 ` Fam Zheng
2016-06-17 13:07 ` Kevin Wolf
2016-06-22 8:27 ` Fam Zheng
2016-06-03 8:49 ` [Qemu-devel] [PATCH v6 09/22] qemu-io: Add "-L" option for BDRV_O_NO_LOCK Fam Zheng
2016-06-03 8:49 ` [Qemu-devel] [PATCH v6 10/22] qemu-img: Add "-L" option to sub commands Fam Zheng
2016-06-03 8:49 ` [Qemu-devel] [PATCH v6 11/22] qemu-img: Update documentation of "-L" option Fam Zheng
2016-06-03 8:49 ` [Qemu-devel] [PATCH v6 12/22] qemu-nbd: Add "--no-lock/-L" option Fam Zheng
2016-06-03 8:49 ` [Qemu-devel] [PATCH v6 13/22] block: Don't lock drive-backup target image in none mode Fam Zheng
2016-06-03 8:49 ` [Qemu-devel] [PATCH v6 14/22] mirror: Disable image locking on target backing chain Fam Zheng
2016-06-06 15:03 ` Max Reitz
2016-06-08 3:22 ` Fam Zheng
2016-06-03 8:49 ` [Qemu-devel] [PATCH v6 15/22] qemu-iotests: 046: Move version detection out from verify_io Fam Zheng
2016-06-03 8:49 ` [Qemu-devel] [PATCH v6 16/22] qemu-iotests: Wait for QEMU processes before checking image in 091 Fam Zheng
2016-06-03 8:49 ` [Qemu-devel] [PATCH v6 17/22] qemu-iotests: 030: Disable image locking when checking test image Fam Zheng
2016-06-03 8:49 ` [Qemu-devel] [PATCH v6 18/22] iotests: 087: Disable image locking in cases where file is shared Fam Zheng
2016-06-03 8:49 ` [Qemu-devel] [PATCH v6 19/22] iotests: Disable image locking in 085 Fam Zheng
2016-06-03 8:49 ` [Qemu-devel] [PATCH v6 20/22] tests: Use null-co:// instead of /dev/null Fam Zheng
2016-06-03 8:49 ` [Qemu-devel] [PATCH v6 21/22] block: Turn on image locking by default Fam Zheng
2016-06-03 8:49 ` [Qemu-devel] [PATCH v6 22/22] qemu-iotests: Add test case 153 for image locking Fam Zheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160622072328.GD22636@ad.usersys.redhat.com \
--to=famz@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=den@openvz.org \
--cc=eblake@redhat.com \
--cc=jcody@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.