From: Kevin Wolf <kwolf@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org, hreitz@redhat.com,
den@openvz.org, alexander.ivanov@virtuozzo.com
Subject: Re: [PATCH v8 5/5] blockdev: qmp_transaction: drop extra generic layer
Date: Wed, 10 May 2023 13:47:22 +0200 [thread overview]
Message-ID: <ZFuESuz8bRcElXaF@redhat.com> (raw)
In-Reply-To: <20230421115327.907104-6-vsementsov@yandex-team.ru>
Am 21.04.2023 um 13:53 hat Vladimir Sementsov-Ogievskiy geschrieben:
> Let's simplify things:
>
> First, actions generally don't need access to common BlkActionState
> structure. The only exclusion are backup actions that need
> block_job_txn.
>
> Next, for transaction actions of Transaction API is more native to
> allocated state structure in the action itself.
>
> So, do the following transformation:
>
> 1. Let all actions be represented by a function with corresponding
> structure as arguments.
>
> 2. Instead of array-map marshaller, let's make a function, that calls
> corresponding action directly.
>
> 3. BlkActionOps and BlkActionState structures become unused
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
> @@ -1973,11 +1910,9 @@ static void blockdev_backup_clean(void *opaque)
> }
>
> typedef struct BlockDirtyBitmapState {
> - BlkActionState common;
> BdrvDirtyBitmap *bitmap;
> BlockDriverState *bs;
> HBitmap *backup;
> - bool prepared;
> bool was_enabled;
> } BlockDirtyBitmapState;
>
> @@ -1987,17 +1922,14 @@ TransactionActionDrv block_dirty_bitmap_add_drv = {
> .clean = g_free,
> };
>
> -static void block_dirty_bitmap_add_action(BlkActionState *common,
> +static void block_dirty_bitmap_add_action(BlockDirtyBitmapAdd *action,
> Transaction *tran, Error **errp)
> {
> Error *local_err = NULL;
> - BlockDirtyBitmapAdd *action;
> - BlockDirtyBitmapState *state = DO_UPCAST(BlockDirtyBitmapState,
> - common, common);
> + BlockDirtyBitmapState *state = g_new0(BlockDirtyBitmapState, 1);
>
> tran_add(tran, &block_dirty_bitmap_add_drv, state);
>
> - action = common->action->u.block_dirty_bitmap_add.data;
> /* AIO context taken and released within qmp_block_dirty_bitmap_add */
> qmp_block_dirty_bitmap_add(action->node, action->name,
> action->has_granularity, action->granularity,
> @@ -2006,7 +1938,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);
> }
> @@ -2014,15 +1947,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);
> }
> }
So you're moving the lookup of the bitmap from .abort to .prepare (or
*_action now). I'm not entirely sure how this is related to the goal of
this specific patch. So the first question is, should it be separate?
The second question is if it is right. Moving it like this means we must
be sure that the bitmap can't be deleted between the lookup and the
.abort call. How can we guarantee this?
On the other hand, we already used &error_abort before, so the
assumption isn't actually new. Just the failure mode changes from
abort() to accessing a dangling pointer, which could be a bit worse.
The rest of the patch looks good.
Kevin
next prev parent reply other threads:[~2023-05-10 11:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-21 11:53 [PATCH v8 0/5] block: refactor blockdev transactions Vladimir Sementsov-Ogievskiy
2023-04-21 11:53 ` [PATCH v8 1/5] blockdev: refactor transaction to use Transaction API Vladimir Sementsov-Ogievskiy
2023-05-10 11:10 ` Kevin Wolf
2023-04-21 11:53 ` [PATCH v8 2/5] blockdev: transactions: rename some things Vladimir Sementsov-Ogievskiy
2023-05-10 11:16 ` Kevin Wolf
2023-04-21 11:53 ` [PATCH v8 3/5] blockdev: qmp_transaction: refactor loop to classic for Vladimir Sementsov-Ogievskiy
2023-05-10 11:17 ` Kevin Wolf
2023-04-21 11:53 ` [PATCH v8 4/5] blockdev: transaction: refactor handling transaction properties Vladimir Sementsov-Ogievskiy
2023-05-10 11:21 ` Kevin Wolf
2023-04-21 11:53 ` [PATCH v8 5/5] blockdev: qmp_transaction: drop extra generic layer Vladimir Sementsov-Ogievskiy
2023-05-10 11:47 ` Kevin Wolf [this message]
2023-05-10 13:37 ` Vladimir Sementsov-Ogievskiy
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=ZFuESuz8bRcElXaF@redhat.com \
--to=kwolf@redhat.com \
--cc=alexander.ivanov@virtuozzo.com \
--cc=den@openvz.org \
--cc=hreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@yandex-team.ru \
/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.