aboutsummaryrefslogtreecommitdiff
path: root/block/vvfat.c
diff options
context:
space:
mode:
authorMax Reitz <mreitz@redhat.com>2014-10-24 12:57:58 +0200
committerStefan Hajnoczi <stefanha@redhat.com>2014-11-03 11:41:47 +0000
commite6d7ec32dd315422a023ed3425fe36df8c274eeb (patch)
tree20426af9713f7ccce90bee16ce91abe90105ad59 /block/vvfat.c
parentf76faeda4bd59f972d09dd9d954297f17c21dd60 (diff)
raw-posix: Fix raw_co_get_block_status() after EOF
As its comment states, raw_co_get_block_status() should unconditionally return 0 and set *pnum to 0 for after EOF. An assertion after lseek(..., SEEK_HOLE) tried to catch this case by asserting that errno != -ENXIO (which would indicate a position after the EOF); but it should be errno != ENXIO instead. Regardless of that, there should be no such assertion at all. If bdrv_getlength() returned an outdated value and the image has been resized outside of qemu, lseek() will return with errno == ENXIO. Just return that value as an error then. Setting *pnum to 0 and returning 0 should not be done here, as in that case we should update the device length as well. So, from qemu's perspective, the file has not been resized; it's just that there was an error querying sectors beyond a certain point (the actual file size). Additionally, nb_sectors should be clamped against the image end. This was probably not an issue if FIEMAP or SEEK_HOLE/SEEK_DATA worked, but the fallback did not take this case into account. Reported-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-id: 1414148280-17949-2-git-send-email-mreitz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Diffstat (limited to 'block/vvfat.c')
0 files changed, 0 insertions, 0 deletions