From: Jeff Cody <jcody@redhat.com>
To: Fam Zheng <famz@redhat.com>
Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-block@nongnu.org,
qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v5 09/12] block: Add "drained begin/end" for internal snapshot
Date: Wed, 21 Oct 2015 14:22:54 -0400 [thread overview]
Message-ID: <20151021182254.GH6466@localhost.localdomain> (raw)
In-Reply-To: <1445393209-26545-10-git-send-email-famz@redhat.com>
On Wed, Oct 21, 2015 at 10:06:46AM +0800, Fam Zheng wrote:
> This ensures the atomicity of the transaction by avoiding processing of
> external requests such as those from ioeventfd.
>
> state->bs is assigned right after bdrv_drained_begin. Because it was
> used as the flag for deletion or not in abort, now we need a separate
> flag - InternalSnapshotState.created.
>
> Signed-off-by: Fam Zheng <famz@redhat.com>
> ---
> blockdev.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/blockdev.c b/blockdev.c
> index 52f44b2..92c2d0d 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -1370,6 +1370,7 @@ typedef struct InternalSnapshotState {
> BlockDriverState *bs;
> AioContext *aio_context;
> QEMUSnapshotInfo sn;
> + bool created;
> } InternalSnapshotState;
>
> static void internal_snapshot_prepare(BlkTransactionState *common,
> @@ -1407,6 +1408,8 @@ static void internal_snapshot_prepare(BlkTransactionState *common,
> /* AioContext is released in .clean() */
> state->aio_context = blk_get_aio_context(blk);
> aio_context_acquire(state->aio_context);
> + state->bs = blk_bs(blk);
> + bdrv_drained_begin(state->bs);
>
Do you think it'd make sense to move the context acquisition & call to
bdrv_drained_begin() below the check for blk_is_available()? That way
the assignment of state->bs doesn't happen until after the call to
blk_is_available(). It looks like state->created protects us either
way, though - but if blk_is_inserted() fails, then there is no need
for _abort or _clean to do anything, if we hold off on grabbing the
context.
I think I am fine with it as is though, too.
> if (!blk_is_available(blk)) {
> error_setg(errp, QERR_DEVICE_HAS_NO_MEDIUM, device);
> @@ -1465,7 +1468,7 @@ static void internal_snapshot_prepare(BlkTransactionState *common,
> }
>
> /* 4. succeed, mark a snapshot is created */
> - state->bs = bs;
> + state->created = true;
> }
>
> static void internal_snapshot_abort(BlkTransactionState *common)
> @@ -1476,7 +1479,7 @@ static void internal_snapshot_abort(BlkTransactionState *common)
> QEMUSnapshotInfo *sn = &state->sn;
> Error *local_error = NULL;
>
> - if (!bs) {
> + if (!state->created) {
> return;
> }
>
> @@ -1497,6 +1500,7 @@ static void internal_snapshot_clean(BlkTransactionState *common)
> common, common);
>
> if (state->aio_context) {
> + bdrv_drained_end(state->bs);
> aio_context_release(state->aio_context);
> }
> }
> --
> 2.4.3
>
>
next prev parent reply other threads:[~2015-10-21 18:23 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-21 2:06 [Qemu-devel] [PATCH v5 00/12] block: Protect nested event loop with bdrv_drained_begin and bdrv_drained_end Fam Zheng
2015-10-21 2:06 ` [Qemu-devel] [PATCH v5 01/12] aio: Add "is_external" flag for event handlers Fam Zheng
2015-10-21 15:21 ` [Qemu-devel] [Qemu-block] " Jeff Cody
2015-10-21 2:06 ` [Qemu-devel] [PATCH v5 02/12] nbd: Mark fd handlers client type as "external" Fam Zheng
2015-10-21 15:21 ` [Qemu-devel] [Qemu-block] " Jeff Cody
2015-10-21 2:06 ` [Qemu-devel] [PATCH v5 03/12] dataplane: Mark host notifiers' " Fam Zheng
2015-10-21 2:06 ` [Qemu-devel] [PATCH v5 04/12] aio: introduce aio_{disable, enable}_external Fam Zheng
2015-10-21 15:56 ` [Qemu-devel] [Qemu-block] " Jeff Cody
2015-10-22 2:11 ` Fam Zheng
2015-10-22 2:20 ` Jeff Cody
2015-10-21 2:06 ` [Qemu-devel] [PATCH v5 05/12] block: Introduce "drained begin/end" API Fam Zheng
2015-10-21 16:11 ` [Qemu-devel] [Qemu-block] " Jeff Cody
2015-10-22 2:20 ` Fam Zheng
2015-10-21 2:06 ` [Qemu-devel] [PATCH v5 06/12] block: Add "drained begin/end" for transactional external snapshot Fam Zheng
2015-10-21 17:18 ` [Qemu-devel] [Qemu-block] " Jeff Cody
2015-10-21 2:06 ` [Qemu-devel] [PATCH v5 07/12] block: Add "drained begin/end" for transactional backup Fam Zheng
2015-10-21 17:20 ` [Qemu-devel] [Qemu-block] " Jeff Cody
2015-10-21 2:06 ` [Qemu-devel] [PATCH v5 08/12] block: Add "drained begin/end" for transactional blockdev-backup Fam Zheng
2015-10-21 17:25 ` [Qemu-devel] [Qemu-block] " Jeff Cody
2015-10-21 2:06 ` [Qemu-devel] [PATCH v5 09/12] block: Add "drained begin/end" for internal snapshot Fam Zheng
2015-10-21 13:37 ` Kevin Wolf
2015-10-21 18:22 ` Jeff Cody [this message]
2015-10-21 2:06 ` [Qemu-devel] [PATCH v5 10/12] block: Introduce BlockDriver.bdrv_drain callback Fam Zheng
2015-10-21 18:25 ` [Qemu-devel] [Qemu-block] " Jeff Cody
2015-10-21 2:06 ` [Qemu-devel] [PATCH v5 11/12] qed: Implement .bdrv_drain Fam Zheng
2015-10-22 2:20 ` [Qemu-devel] [Qemu-block] " Jeff Cody
2015-10-22 2:59 ` Fam Zheng
2015-10-21 2:06 ` [Qemu-devel] [PATCH v5 12/12] tests: Add test case for aio_disable_external Fam Zheng
2015-10-21 13:40 ` [Qemu-devel] [PATCH v5 00/12] block: Protect nested event loop with bdrv_drained_begin and bdrv_drained_end Kevin Wolf
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=20151021182254.GH6466@localhost.localdomain \
--to=jcody@redhat.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).