aboutsummaryrefslogtreecommitdiff
path: root/.editorconfig
diff options
context:
space:
mode:
authorHanna Reitz <hreitz@redhat.com>2022-03-14 17:27:18 +0100
committerKevin Wolf <kwolf@redhat.com>2022-05-04 15:55:23 +0200
commit6d17e2879854d7d0e623c06a9286085e97bf3545 (patch)
treee3f230f77b728f6f58c2efedf043c2b4ef238131 /.editorconfig
parent96edda8f142928c627f93b3ad74c64edf86cc22f (diff)
block/vmdk: Fix reopening bs->file
VMDK disk data is stored in extents, which may or may not be separate from bs->file. VmdkExtent.file points to where they are stored. Each that is stored in bs->file will simply reuse the exact pointer value of bs->file. (That is why vmdk_free_extents() will unref VmdkExtent.file (e->file) only if e->file != bs->file.) Reopen operations can change bs->file (they will replace the whole BdrvChild object, not just the BDS stored in that BdrvChild), and then we will need to change all .file pointers of all such VmdkExtents to point to the new BdrvChild. In vmdk_reopen_prepare(), we have to check which VmdkExtents are affected, and in vmdk_reopen_commit(), we can modify them. We have to split this because: - The new BdrvChild is created only after prepare, so we can change VmdkExtent.file only in commit - In commit, there no longer is any (valid) reference to the old BdrvChild object, so there would be nothing to compare VmdkExtent.file against to see whether it was equal to bs->file before reopening (There is BDRVReopenState.old_file_bs, but the old bs->file BdrvChild's .bs pointer will be NULL-ed when the new BdrvChild is created, and so we cannot compare VmdkExtent.file->bs against BDRVReopenState.old_file_bs) Signed-off-by: Hanna Reitz <hreitz@redhat.com> Message-Id: <20220314162719.65384-2-hreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to '.editorconfig')
0 files changed, 0 insertions, 0 deletions