summaryrefslogtreecommitdiffstats
path: root/python/qemu/utils
diff options
context:
space:
mode:
authorMax Reitz2021-05-03 11:54:18 +0200
committerMax Reitz2021-06-24 09:49:04 +0200
commit32a9a245d719a883eef2cbf07d2cf89efa0206d0 (patch)
treecc60a72f0b7d281293a3cbef0bbfa7cbc86701c2 /python/qemu/utils
parentMerge remote-tracking branch 'remotes/vivier2/tags/linux-user-for-6.1-pull-re... (diff)
downloadqemu-32a9a245d719a883eef2cbf07d2cf89efa0206d0.tar.gz
qemu-32a9a245d719a883eef2cbf07d2cf89efa0206d0.tar.xz
qemu-32a9a245d719a883eef2cbf07d2cf89efa0206d0.zip
block/snapshot: Clarify goto fallback behavior
In the bdrv_snapshot_goto() fallback code, we work with a pointer to either bs->file or bs->backing. We detach that child, close the node (with .bdrv_close()), apply the snapshot on the child node, and then re-open the node (with .bdrv_open()). In order for .bdrv_open() to attach the same child node that we had before, we pass "file={child-node}" or "backing={child-node}" to it. Therefore, when .bdrv_open() has returned success, we can assume that bs->file or bs->backing (respectively) points to our original child again. This is verified by an assertion. All of this is not immediately clear from a quick glance at the code, so add a comment to the assertion what it is for, and why it is valid. It certainly confused Coverity. Reported-by: Coverity (CID 1452774) Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20210503095418.31521-1-mreitz@redhat.com> [mreitz: s/close/detach/] Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Diffstat (limited to 'python/qemu/utils')
0 files changed, 0 insertions, 0 deletions