From: Kevin Wolf <kwolf@redhat.com>
To: qemu-block@nongnu.org
Cc: kwolf@redhat.com, richard.henderson@linaro.org, qemu-devel@nongnu.org
Subject: [PULL 05/18] blockdev: use state.bitmap in block-dirty-bitmap-add action
Date: Wed, 17 May 2023 18:51:03 +0200 [thread overview]
Message-ID: <20230517165116.475123-6-kwolf@redhat.com> (raw)
In-Reply-To: <20230517165116.475123-1-kwolf@redhat.com>
From: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Other bitmap related actions use the .bitmap pointer in .abort action,
let's do same here:
1. It helps further refactoring, as bitmap-add is the only bitmap
action that uses state.action in .abort
2. It must be safe: transaction actions rely on the fact that on
.abort() the state is the same as at the end of .prepare(), so that
in .abort() we could precisely rollback the changes done by
.prepare().
The only way to remove the bitmap during transaction should be
block-dirty-bitmap-remove action, but it postpones actual removal to
.commit(), so we are OK on any rollback path. (Note also that
bitmap-remove is the only bitmap action that has .commit() phase,
except for simple g_free the state on .clean())
3. Again, other bitmap actions behave this way: keep the bitmap pointer
during the transaction.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Message-Id: <20230510150624.310640-6-vsementsov@yandex-team.ru>
[kwolf: Also remove the now unused BlockDirtyBitmapState.prepared]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
---
blockdev.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index a2ebaa5afc..4bf15566b2 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1979,7 +1979,6 @@ typedef struct BlockDirtyBitmapState {
BdrvDirtyBitmap *bitmap;
BlockDriverState *bs;
HBitmap *backup;
- bool prepared;
bool was_enabled;
} BlockDirtyBitmapState;
@@ -2008,7 +2007,8 @@ static void block_dirty_bitmap_add_action(BlkActionState *common,
&local_err);
if (!local_err) {
- state->prepared = true;
+ state->bitmap = block_dirty_bitmap_lookup(action->node, action->name,
+ NULL, &error_abort);
} else {
error_propagate(errp, local_err);
}
@@ -2016,15 +2016,10 @@ static void block_dirty_bitmap_add_action(BlkActionState *common,
static void block_dirty_bitmap_add_abort(void *opaque)
{
- BlockDirtyBitmapAdd *action;
BlockDirtyBitmapState *state = opaque;
- action = state->common.action->u.block_dirty_bitmap_add.data;
- /* Should not be able to fail: IF the bitmap was added via .prepare(),
- * then the node reference and bitmap name must have been valid.
- */
- if (state->prepared) {
- qmp_block_dirty_bitmap_remove(action->node, action->name, &error_abort);
+ if (state->bitmap) {
+ bdrv_release_dirty_bitmap(state->bitmap);
}
}
--
2.40.1
next prev parent reply other threads:[~2023-05-17 16:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 16:50 [PULL 00/18] Block layer patches Kevin Wolf
2023-05-17 16:50 ` [PULL 01/18] blockdev: refactor transaction to use Transaction API Kevin Wolf
2023-05-17 16:51 ` [PULL 02/18] blockdev: transactions: rename some things Kevin Wolf
2023-05-17 16:51 ` [PULL 03/18] blockdev: qmp_transaction: refactor loop to classic for Kevin Wolf
2023-05-17 16:51 ` [PULL 04/18] blockdev: transaction: refactor handling transaction properties Kevin Wolf
2023-05-17 16:51 ` Kevin Wolf [this message]
2023-05-17 16:51 ` [PULL 06/18] blockdev: qmp_transaction: drop extra generic layer Kevin Wolf
2023-05-17 16:51 ` [PULL 07/18] docs/interop/qcow2.txt: fix description about "zlib" clusters Kevin Wolf
2023-05-17 16:51 ` [PULL 08/18] block: Call .bdrv_co_create(_opts) unlocked Kevin Wolf
2023-05-17 16:51 ` [PULL 09/18] block/export: Fix null pointer dereference in error path Kevin Wolf
2023-05-17 16:51 ` [PULL 10/18] qcow2: Unlock the graph in qcow2_do_open() where necessary Kevin Wolf
2023-05-17 16:51 ` [PULL 11/18] qemu-img: Take graph lock more selectively Kevin Wolf
2023-05-17 16:51 ` [PULL 12/18] test-bdrv-drain: " Kevin Wolf
2023-05-17 16:51 ` [PULL 13/18] test-bdrv-drain: Call bdrv_co_unref() in coroutine context Kevin Wolf
2023-05-17 16:51 ` [PULL 14/18] blockjob: Adhere to rate limit even when reentered early Kevin Wolf
2023-05-17 16:51 ` [PULL 15/18] graph-lock: Honour read locks even in the main thread Kevin Wolf
2023-05-17 16:51 ` [PULL 16/18] iotests/245: Check if 'compress' driver is available Kevin Wolf
2023-05-17 16:51 ` [PULL 17/18] aio-posix: do not nest poll handlers Kevin Wolf
2023-05-18 7:13 ` Michael Tokarev
2023-05-18 15:05 ` Stefan Hajnoczi
2023-05-17 16:51 ` [PULL 18/18] tested: add test for nested aio_poll() in " Kevin Wolf
2023-05-17 19:10 ` Richard Henderson
2023-05-19 9:23 ` Kevin Wolf
2023-05-23 15:36 ` Stefan Hajnoczi
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=20230517165116.475123-6-kwolf@redhat.com \
--to=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/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).