diff options
author | Peter Maydell <peter.maydell@linaro.org> | 2024-10-08 17:47:08 +0100 |
---|---|---|
committer | Kevin Wolf <kwolf@redhat.com> | 2024-10-22 17:52:49 +0200 |
commit | 4d7c5f8335dad1aac9bf00704dab5409b9a9f4db (patch) | |
tree | 5db69d3e522966e980bc1182e27c5a84cf1bdf08 /module-common.c | |
parent | d60bd080e783107cb876a6f16561fe03f9dcbca7 (diff) | |
download | qemu-4d7c5f8335dad1aac9bf00704dab5409b9a9f4db.zip qemu-4d7c5f8335dad1aac9bf00704dab5409b9a9f4db.tar.gz qemu-4d7c5f8335dad1aac9bf00704dab5409b9a9f4db.tar.bz2 |
block/vdi.c: Make SECTOR_SIZE constant 64-bits
Make the VDI SECTOR_SIZE define be a 64-bit constant; this matches
how we define BDRV_SECTOR_SIZE. The benefit is that it means that we
don't need to carefully cast to 64-bits when doing operations like
"n_sectors * SECTOR_SIZE" to avoid doing a 32x32->32 multiply, which
might overflow, and which Coverity and other static analysers tend to
warn about.
The specific potential overflow Coverity is highlighting is the one
at the end of vdi_co_pwritev() where we write out n_sectors sectors
to the block map. This is very unlikely to actually overflow, since
the block map has 4 bytes per block and the maximum number of blocks
in the image must fit into a 32-bit integer. So this commit is not
fixing a real-world bug.
An inspection of all the places currently using SECTOR_SIZE in the
file shows none which care about the change in its type, except for
one call to error_setg() which needs the format string adjusting.
Resolves: Coverity CID 1508076
Suggested-by: Kevin Wolf <kwolf@redhat.com>
Message-ID: <20241008164708.2966400-5-peter.maydell@linaro.org>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'module-common.c')
0 files changed, 0 insertions, 0 deletions