| Message ID | 20181116164526.31487-2-mreitz@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [for-3.1?,v2,1/3] block: Always abort reopen after prepare succeeded | expand |
On Fri 16 Nov 2018 05:45:24 PM CET, Max Reitz wrote: > bdrv_reopen_multiple() does not invoke bdrv_reopen_abort() for the > element of the reopen queue for which bdrv_reopen_prepare() failed, > because it assumes that the prepare function will have rolled back all > changes already. > > However, bdrv_reopen_prepare() does not do this in every case: It may > notice an error after BlockDriver.bdrv_reopen_prepare() succeeded, and > it will not invoke BlockDriver.bdrv_reopen_abort() then; and neither > will bdrv_reopen_multiple(), as explained above. > > This is wrong because we must always call .bdrv_reopen_commit() or > .bdrv_reopen_abort() after .bdrv_reopen_prepare() has succeeded. > Otherwise, the block driver has no chance to undo what it has done in > its implementation of .bdrv_reopen_prepare(). > > To fix this, bdrv_reopen_prepare() has to call .bdrv_reopen_abort() if > it wants to return an error after .bdrv_reopen_prepare() has succeeded. > > Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Berto
diff --git a/block.c b/block.c index fd67e14dfa..3feac08535 100644 --- a/block.c +++ b/block.c @@ -3201,6 +3201,7 @@ int bdrv_reopen_prepare(BDRVReopenState *reopen_state, BlockReopenQueue *queue, QDict *orig_reopen_opts; char *discard = NULL; bool read_only; + bool drv_prepared = false; assert(reopen_state != NULL); assert(reopen_state->bs->drv != NULL); @@ -3285,6 +3286,8 @@ int bdrv_reopen_prepare(BDRVReopenState *reopen_state, BlockReopenQueue *queue, goto error; } + drv_prepared = true; + /* Options that are not handled are only okay if they are unchanged * compared to the old state. It is expected that some options are only * used for the initial open, but not reopen (e.g. filename) */ @@ -3350,6 +3353,15 @@ int bdrv_reopen_prepare(BDRVReopenState *reopen_state, BlockReopenQueue *queue, reopen_state->options = qobject_ref(orig_reopen_opts); error: + if (ret < 0 && drv_prepared) { + /* drv->bdrv_reopen_prepare() has succeeded, so we need to + * call drv->bdrv_reopen_abort() before signaling an error + * (bdrv_reopen_multiple() will not call bdrv_reopen_abort() + * when the respective bdrv_reopen_prepare() has failed) */ + if (drv->bdrv_reopen_abort) { + drv->bdrv_reopen_abort(reopen_state); + } + } qemu_opts_del(opts); qobject_unref(orig_reopen_opts); g_free(discard);
bdrv_reopen_multiple() does not invoke bdrv_reopen_abort() for the element of the reopen queue for which bdrv_reopen_prepare() failed, because it assumes that the prepare function will have rolled back all changes already. However, bdrv_reopen_prepare() does not do this in every case: It may notice an error after BlockDriver.bdrv_reopen_prepare() succeeded, and it will not invoke BlockDriver.bdrv_reopen_abort() then; and neither will bdrv_reopen_multiple(), as explained above. This is wrong because we must always call .bdrv_reopen_commit() or .bdrv_reopen_abort() after .bdrv_reopen_prepare() has succeeded. Otherwise, the block driver has no chance to undo what it has done in its implementation of .bdrv_reopen_prepare(). To fix this, bdrv_reopen_prepare() has to call .bdrv_reopen_abort() if it wants to return an error after .bdrv_reopen_prepare() has succeeded. Signed-off-by: Max Reitz <mreitz@redhat.com> --- block.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)