diff options
| author | Max Reitz <mreitz@redhat.com> | 2018-11-16 17:45:24 +0100 |
|---|---|---|
| committer | Kevin Wolf <kwolf@redhat.com> | 2018-11-19 14:31:48 +0100 |
| commit | 9ad08c44566bf4466c6263c71d43e9f7a354d4ba (patch) | |
| tree | 707878ec689e2e50d1cfb10bdfafe3e3ac0415e2 /hw/timer/stm32f2xx_timer.c | |
| parent | 3b94c343f98b660e1c1cf79a8f704151962ecd48 (diff) | |
| download | focaccia-qemu-9ad08c44566bf4466c6263c71d43e9f7a354d4ba.tar.gz focaccia-qemu-9ad08c44566bf4466c6263c71d43e9f7a354d4ba.zip | |
block: Always abort reopen after prepare succeeded
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> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'hw/timer/stm32f2xx_timer.c')
0 files changed, 0 insertions, 0 deletions