qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [PATCH 111/113] qemu-img: Fix assert when mapping unaligned


From: Michael Roth
Subject: [Qemu-devel] [PATCH 111/113] qemu-img: Fix assert when mapping unaligned raw file
Date: Mon, 18 Jun 2018 20:43:17 -0500

From: Eric Blake <address@hidden>

Commit a290f085 exposed a latent bug in qemu-img map introduced
during the conversion of block status to be byte-based.  Earlier in
commit 5e344dd8, the internal interface get_block_status() switched
to take byte-based parameters, but still called a sector-based
block layer function; as such, rounding was added in the lone
caller to obey the contract.  However, commit 237d78f8 changed
get_block_status() to truly be byte-based, at which point rounding
to sector boundaries can result in calling bdrv_block_status() with
'bytes == 0' (a coding error) when the boundary between data and a
hole falls mid-sector (true for the past-EOF implicit hole present
in POSIX files).  Fix things by removing the rounding that is now
no longer necessary.

See also https://bugzilla.redhat.com/1589738

Fixes: 237d78f8
Reported-by: Dan Kenigsberg <address@hidden>
Reported-by: Nir Soffer <address@hidden>
Reported-by: Maor Lipchuk <address@hidden>
CC: address@hidden
Signed-off-by: Eric Blake <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit e0b371ed5e2db079051139136fd0478728b6a58f)
Signed-off-by: Michael Roth <address@hidden>
---
 qemu-img.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/qemu-img.c b/qemu-img.c
index 86060aab71..bf9de27893 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -2826,7 +2826,7 @@ static int img_map(int argc, char **argv)
         int64_t n;
 
         /* Probe up to 1 GiB at a time.  */
-        n = QEMU_ALIGN_DOWN(MIN(1 << 30, length - offset), BDRV_SECTOR_SIZE);
+        n = MIN(1 << 30, length - offset);
         ret = get_block_status(bs, offset, n, &next);
 
         if (ret < 0) {
-- 
2.11.0




reply via email to

[Prev in Thread] Current Thread [Next in Thread]