diff options
author | Paolo Bonzini <pbonzini@redhat.com> | 2011-10-20 13:16:20 +0200 |
---|---|---|
committer | Kevin Wolf <kwolf@redhat.com> | 2011-10-21 17:34:13 +0200 |
commit | bae0a0cc38d324c83ba737b92215f3447981d73b (patch) | |
tree | f5e89d14669f1068a999d8aed22a795bb4195142 /block/vpc.c | |
parent | 588b65a37abf7bbe47c3a7243a871d83fa1aa66b (diff) |
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