qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] [PATCH v2] block/vdi: Limit maximum size even futher
@ 2014-10-28 10:12 Max Reitz
  2014-11-06  9:25 ` Max Reitz
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Max Reitz @ 2014-10-28 10:12 UTC (permalink / raw)
  To: qemu-devel
  Cc: Kevin Wolf, Stefan Weil, Jeff Cody, Peter Lieven, Max Reitz,
	Stefan Hajnoczi

The block layer read and write functions do not like requests which are
bigger than INT_MAX bytes. Since the VDI bmap is read and written in a
single operation, its size is therefore limited accordingly. This
reduces the maximum VDI image size supported by QEMU to half of what it
currently is (down to approximately 512 TB).

The VDI test 084 has to be adapted accordingly. Actually, one could
clearly see that it was broken from the "Could not open
'TEST_DIR/t.IMGFMT': Invalid argument" line for an image which was
supposed to work just fine.

Signed-off-by: Max Reitz <mreitz@redhat.com>
---
v2:
- Reducing the size to just under 512 TB wasn't enough because the bmap
  size is rounded up on sector boundaries; fixed (thanks for testing,
  Peter)
- Finally a patch regarding this problem that I tested myself :-)
---
 block/vdi.c                | 14 ++++++++++++--
 tests/qemu-iotests/084     | 14 +++++++-------
 tests/qemu-iotests/084.out | 13 ++++++++-----
 3 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/block/vdi.c b/block/vdi.c
index 19701ee..0305810 100644
--- a/block/vdi.c
+++ b/block/vdi.c
@@ -120,8 +120,18 @@ typedef unsigned char uuid_t[16];
 
 #define VDI_IS_ALLOCATED(X) ((X) < VDI_DISCARDED)
 
-/* max blocks in image is (0xffffffff / 4) */
-#define VDI_BLOCKS_IN_IMAGE_MAX  0x3fffffff
+/* The bmap will take up VDI_BLOCKS_IN_IMAGE_MAX * sizeof(uint32_t) bytes; since
+ * the bmap is read and written in a single operation, its size needs to be
+ * limited to INT_MAX; furthermore, when opening an image, the bmap size is
+ * rounded up to be aligned on BDRV_SECTOR_SIZE.
+ * Therefore this should satisfy the following:
+ * VDI_BLOCKS_IN_IMAGE_MAX * sizeof(uint32_t) + BDRV_SECTOR_SIZE == INT_MAX + 1
+ * (INT_MAX + 1 is the first value not representable as an int)
+ * This guarantees that any value below or equal to the constant will, when
+ * multiplied by sizeof(uint32_t) and rounded up to a BDRV_SECTOR_SIZE boundary,
+ * still be below or equal to INT_MAX. */
+#define VDI_BLOCKS_IN_IMAGE_MAX \
+    ((unsigned)((INT_MAX + 1u - BDRV_SECTOR_SIZE) / sizeof(uint32_t)))
 #define VDI_DISK_SIZE_MAX        ((uint64_t)VDI_BLOCKS_IN_IMAGE_MAX * \
                                   (uint64_t)DEFAULT_CLUSTER_SIZE)
 
diff --git a/tests/qemu-iotests/084 b/tests/qemu-iotests/084
index 2712c02..733018d 100755
--- a/tests/qemu-iotests/084
+++ b/tests/qemu-iotests/084
@@ -66,15 +66,15 @@ stat -c"disk image file size in bytes: %s" "${TEST_IMG}"
 
 # check for image size too large
 # poke max image size, and appropriate blocks_in_image value
-echo "Test 1: Maximum size (1024 TB):"
-poke_file "$TEST_IMG" "$ds_offset" "\x00\x00\xf0\xff\xff\xff\x03\x00"
-poke_file "$TEST_IMG" "$bii_offset" "\xff\xff\xff\x3f"
+echo "Test 1: Maximum size (512 TB - 128 MB):"
+poke_file "$TEST_IMG" "$ds_offset" "\x00\x00\x00\xf8\xff\xff\x01\x00"
+poke_file "$TEST_IMG" "$bii_offset" "\x80\xff\xff\x1f"
 _img_info
 
 echo
-echo "Test 2: Size too large (1024TB + 1)"
+echo "Test 2: Size too large (512 TB - 128 MB + 64 kB)"
 # This should be too large (-EINVAL):
-poke_file "$TEST_IMG" "$ds_offset" "\x00\x00\xf1\xff\xff\xff\x03\x00"
+poke_file "$TEST_IMG" "$ds_offset" "\x00\x00\x01\xf8\xff\xff\x01\x00"
 _img_info
 
 echo
@@ -89,9 +89,9 @@ _img_info
 
 echo
 echo "Test 4: Size valid (64M), but Blocks In Image exceeds max allowed"
-# Now check the bounds of blocks_in_image - 0x3fffffff should be the max
+# Now check the bounds of blocks_in_image - 0x1fffff80 should be the max
 # value here, and we should get -ENOTSUP
-poke_file "$TEST_IMG" "$bii_offset" "\x00\x00\x00\x40"
+poke_file "$TEST_IMG" "$bii_offset" "\x81\xff\xff\x1f"
 _img_info
 
 # Finally, 1MB is the only block size supported.  Verify that
diff --git a/tests/qemu-iotests/084.out b/tests/qemu-iotests/084.out
index ea29ae0..5ece829 100644
--- a/tests/qemu-iotests/084.out
+++ b/tests/qemu-iotests/084.out
@@ -17,17 +17,20 @@ file format: IMGFMT
 virtual size: 64M (67108864 bytes)
 cluster_size: 1048576
 disk image file size in bytes: 1024
-Test 1: Maximum size (1024 TB):
-qemu-img: Could not open 'TEST_DIR/t.IMGFMT': Could not open 'TEST_DIR/t.IMGFMT': Invalid argument
+Test 1: Maximum size (512 TB - 128 MB):
+image: TEST_DIR/t.IMGFMT
+file format: IMGFMT
+virtual size: 512T (562949819203584 bytes)
+cluster_size: 1048576
 
-Test 2: Size too large (1024TB + 1)
-qemu-img: Could not open 'TEST_DIR/t.IMGFMT': Unsupported VDI image size (size is 0x3fffffff10000, max supported is 0x3fffffff00000)
+Test 2: Size too large (512 TB - 128 MB + 64 kB)
+qemu-img: Could not open 'TEST_DIR/t.IMGFMT': Unsupported VDI image size (size is 0x1fffff8010000, max supported is 0x1fffff8000000)
 
 Test 3: Size valid (64M), but Blocks In Image too small (63)
 qemu-img: Could not open 'TEST_DIR/t.IMGFMT': unsupported VDI image (disk size 67108864, image bitmap has room for 66060288)
 
 Test 4: Size valid (64M), but Blocks In Image exceeds max allowed
-qemu-img: Could not open 'TEST_DIR/t.IMGFMT': unsupported VDI image (too many blocks 1073741824, max is 1073741823)
+qemu-img: Could not open 'TEST_DIR/t.IMGFMT': unsupported VDI image (too many blocks 536870785, max is 536870784)
 
 Test 5: Valid Image: 64MB, Blocks In Image 64, Block Size 1MB
 image: TEST_DIR/t.IMGFMT
-- 
1.9.3

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [Qemu-devel] [PATCH v2] block/vdi: Limit maximum size even futher
  2014-10-28 10:12 [Qemu-devel] [PATCH v2] block/vdi: Limit maximum size even futher Max Reitz
@ 2014-11-06  9:25 ` Max Reitz
  2014-11-06 13:06 ` Stefan Hajnoczi
  2014-11-07  9:04 ` Max Reitz
  2 siblings, 0 replies; 5+ messages in thread
From: Max Reitz @ 2014-11-06  9:25 UTC (permalink / raw)
  To: qemu-devel
  Cc: Kevin Wolf, Stefan Weil, Jeff Cody, Peter Lieven, Stefan Hajnoczi

On 2014-10-28 at 11:12, Max Reitz wrote:
> The block layer read and write functions do not like requests which are
> bigger than INT_MAX bytes. Since the VDI bmap is read and written in a
> single operation, its size is therefore limited accordingly. This
> reduces the maximum VDI image size supported by QEMU to half of what it
> currently is (down to approximately 512 TB).
>
> The VDI test 084 has to be adapted accordingly. Actually, one could
> clearly see that it was broken from the "Could not open
> 'TEST_DIR/t.IMGFMT': Invalid argument" line for an image which was
> supposed to work just fine.
>
> Signed-off-by: Max Reitz <mreitz@redhat.com>
> ---
> v2:
> - Reducing the size to just under 512 TB wasn't enough because the bmap
>    size is rounded up on sector boundaries; fixed (thanks for testing,
>    Peter)
> - Finally a patch regarding this problem that I tested myself :-)

Ping

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Qemu-devel] [PATCH v2] block/vdi: Limit maximum size even futher
  2014-10-28 10:12 [Qemu-devel] [PATCH v2] block/vdi: Limit maximum size even futher Max Reitz
  2014-11-06  9:25 ` Max Reitz
@ 2014-11-06 13:06 ` Stefan Hajnoczi
  2014-11-06 13:28   ` Peter Lieven
  2014-11-07  9:04 ` Max Reitz
  2 siblings, 1 reply; 5+ messages in thread
From: Stefan Hajnoczi @ 2014-11-06 13:06 UTC (permalink / raw)
  To: Max Reitz; +Cc: Kevin Wolf, Stefan Weil, Jeff Cody, Peter Lieven, qemu-devel

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

On Tue, Oct 28, 2014 at 11:12:32AM +0100, Max Reitz wrote:
> The block layer read and write functions do not like requests which are
> bigger than INT_MAX bytes. Since the VDI bmap is read and written in a
> single operation, its size is therefore limited accordingly. This
> reduces the maximum VDI image size supported by QEMU to half of what it
> currently is (down to approximately 512 TB).
> 
> The VDI test 084 has to be adapted accordingly. Actually, one could
> clearly see that it was broken from the "Could not open
> 'TEST_DIR/t.IMGFMT': Invalid argument" line for an image which was
> supposed to work just fine.
> 
> Signed-off-by: Max Reitz <mreitz@redhat.com>
> ---
> v2:
> - Reducing the size to just under 512 TB wasn't enough because the bmap
>   size is rounded up on sector boundaries; fixed (thanks for testing,
>   Peter)
> - Finally a patch regarding this problem that I tested myself :-)
> ---
>  block/vdi.c                | 14 ++++++++++++--
>  tests/qemu-iotests/084     | 14 +++++++-------
>  tests/qemu-iotests/084.out | 13 ++++++++-----
>  3 files changed, 27 insertions(+), 14 deletions(-)

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Qemu-devel] [PATCH v2] block/vdi: Limit maximum size even futher
  2014-11-06 13:06 ` Stefan Hajnoczi
@ 2014-11-06 13:28   ` Peter Lieven
  0 siblings, 0 replies; 5+ messages in thread
From: Peter Lieven @ 2014-11-06 13:28 UTC (permalink / raw)
  To: Stefan Hajnoczi, Max Reitz; +Cc: Kevin Wolf, Stefan Weil, Jeff Cody, qemu-devel

On 06.11.2014 14:06, Stefan Hajnoczi wrote:
> On Tue, Oct 28, 2014 at 11:12:32AM +0100, Max Reitz wrote:
>> The block layer read and write functions do not like requests which are
>> bigger than INT_MAX bytes. Since the VDI bmap is read and written in a
>> single operation, its size is therefore limited accordingly. This
>> reduces the maximum VDI image size supported by QEMU to half of what it
>> currently is (down to approximately 512 TB).
>>
>> The VDI test 084 has to be adapted accordingly. Actually, one could
>> clearly see that it was broken from the "Could not open
>> 'TEST_DIR/t.IMGFMT': Invalid argument" line for an image which was
>> supposed to work just fine.
>>
>> Signed-off-by: Max Reitz <mreitz@redhat.com>
>> ---
>> v2:
>> - Reducing the size to just under 512 TB wasn't enough because the bmap
>>    size is rounded up on sector boundaries; fixed (thanks for testing,
>>    Peter)
>> - Finally a patch regarding this problem that I tested myself :-)
>> ---
>>   block/vdi.c                | 14 ++++++++++++--
>>   tests/qemu-iotests/084     | 14 +++++++-------
>>   tests/qemu-iotests/084.out | 13 ++++++++-----
>>   3 files changed, 27 insertions(+), 14 deletions(-)
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

Reviewed-by: Peter Lieven <pl@kamp.de>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Qemu-devel] [PATCH v2] block/vdi: Limit maximum size even futher
  2014-10-28 10:12 [Qemu-devel] [PATCH v2] block/vdi: Limit maximum size even futher Max Reitz
  2014-11-06  9:25 ` Max Reitz
  2014-11-06 13:06 ` Stefan Hajnoczi
@ 2014-11-07  9:04 ` Max Reitz
  2 siblings, 0 replies; 5+ messages in thread
From: Max Reitz @ 2014-11-07  9:04 UTC (permalink / raw)
  To: qemu-devel
  Cc: Kevin Wolf, Stefan Weil, Jeff Cody, Peter Lieven, Stefan Hajnoczi

On 2014-10-28 at 11:12, Max Reitz wrote:
> The block layer read and write functions do not like requests which are
> bigger than INT_MAX bytes. Since the VDI bmap is read and written in a
> single operation, its size is therefore limited accordingly. This
> reduces the maximum VDI image size supported by QEMU to half of what it
> currently is (down to approximately 512 TB).
>
> The VDI test 084 has to be adapted accordingly. Actually, one could
> clearly see that it was broken from the "Could not open
> 'TEST_DIR/t.IMGFMT': Invalid argument" line for an image which was
> supposed to work just fine.
>
> Signed-off-by: Max Reitz <mreitz@redhat.com>
> ---
> v2:
> - Reducing the size to just under 512 TB wasn't enough because the bmap
>    size is rounded up on sector boundaries; fixed (thanks for testing,
>    Peter)
> - Finally a patch regarding this problem that I tested myself :-)
> ---
>   block/vdi.c                | 14 ++++++++++++--
>   tests/qemu-iotests/084     | 14 +++++++-------
>   tests/qemu-iotests/084.out | 13 ++++++++-----
>   3 files changed, 27 insertions(+), 14 deletions(-)

Thanks for the reviews, applied to my block branch:

https://github.com/XanClic/qemu/commits/block

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2014-11-07  9:04 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-28 10:12 [Qemu-devel] [PATCH v2] block/vdi: Limit maximum size even futher Max Reitz
2014-11-06  9:25 ` Max Reitz
2014-11-06 13:06 ` Stefan Hajnoczi
2014-11-06 13:28   ` Peter Lieven
2014-11-07  9:04 ` Max Reitz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).