summaryrefslogtreecommitdiff
path: root/block/vpc.c
diff options
context:
space:
mode:
authorPaolo Bonzini <pbonzini@redhat.com>2011-10-20 13:16:20 +0200
committerKevin Wolf <kwolf@redhat.com>2011-10-21 17:34:13 +0200
commitbae0a0cc38d324c83ba737b92215f3447981d73b (patch)
treef5e89d14669f1068a999d8aed22a795bb4195142 /block/vpc.c
parent588b65a37abf7bbe47c3a7243a871d83fa1aa66b (diff)
downloadqemu-bae0a0cc38d324c83ba737b92215f3447981d73b.tar.gz
vmdk: clean up open
Move vmdk_parent_open to vmdk_open. There's another path how vmdk_parent_open can be reached: vmdk_parse_extents() -> vmdk_open_sparse() -> vmdk_open_vmdk4() -> vmdk_open_desc_file(). If that can happen, however, the code is bogus. vmdk_parent_open reads from bs->file: if (bdrv_pread(bs->file, s->desc_offset, desc, DESC_SIZE) != DESC_SIZE) { but it is always called with s->desc_offset == 0 and with the same bs->file. So the data that vmdk_parent_open reads comes always from the same place, and anyway there is only one place where it can write it, namely bs->backing_file. So, if it cannot happen, the patched code is okay. It is also possible that the recursive call can happen, but only once. In that case there would still be a bug in vmdk_open_desc_file setting s->desc_offset = 0, but the patched code is okay. Finally, in the case where multiple recursive calls can happen the code would need to be rewritten anyway. It is likely that this would anyway involve adding several parameters to vmdk_parent_open, and calling it from vmdk_open_vmdk4. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'block/vpc.c')
0 files changed, 0 insertions, 0 deletions