|
 |
218e99 |
From 71930418e15b0acb825fbd02dc4f954ccdea6ece Mon Sep 17 00:00:00 2001
|
|
|
218e99 |
From: Fam Zheng <famz@redhat.com>
|
|
|
218e99 |
Date: Mon, 19 Aug 2013 18:54:25 +0800
|
|
|
218e99 |
Subject: [PATCH 10/13] vmdk: Move l1_size check into vmdk_add_extent()
|
|
|
218e99 |
|
|
|
218e99 |
Message-id: <1377573001-27070-11-git-send-email-famz@redhat.com>
|
|
|
218e99 |
Patchwork-id: 53790
|
|
|
218e99 |
O-Subject: [RHEL-7 qemu-kvm PATCH 10/13] vmdk: Move l1_size check into
|
|
|
218e99 |
vmdk_add_extent()
|
|
|
218e99 |
Bugzilla: 995866
|
|
|
218e99 |
RH-Acked-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
218e99 |
RH-Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
|
|
|
218e99 |
RH-Acked-by: Kevin Wolf <kwolf@redhat.com>
|
|
|
218e99 |
|
|
|
218e99 |
This header check is common to VMDK3 and VMDK4, so move it into
|
|
|
218e99 |
vmdk_add_extent().
|
|
|
218e99 |
|
|
|
218e99 |
Signed-off-by: Fam Zheng <famz@redhat.com>
|
|
|
218e99 |
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
|
|
|
218e99 |
(cherry picked from commit b0651b8c246d0d9e6ad0831b3e34fd756016ad7e)
|
|
|
218e99 |
Signed-off-by: Fam Zheng <famz@redhat.com>
|
|
|
218e99 |
---
|
|
|
218e99 |
block/vmdk.c | 16 ++++++++--------
|
|
|
218e99 |
1 files changed, 8 insertions(+), 8 deletions(-)
|
|
|
218e99 |
|
|
|
218e99 |
diff --git a/block/vmdk.c b/block/vmdk.c
|
|
|
218e99 |
index 73d9907..4388038 100644
|
|
|
218e99 |
--- a/block/vmdk.c
|
|
|
218e99 |
+++ b/block/vmdk.c
|
|
|
218e99 |
@@ -401,6 +401,14 @@ static int vmdk_add_extent(BlockDriverState *bs,
|
|
|
218e99 |
error_report("invalid granularity, image may be corrupt");
|
|
|
218e99 |
return -EINVAL;
|
|
|
218e99 |
}
|
|
|
218e99 |
+ if (l1_size > 512 * 1024 * 1024) {
|
|
|
218e99 |
+ /* Although with big capacity and small l1_entry_sectors, we can get a
|
|
|
218e99 |
+ * big l1_size, we don't want unbounded value to allocate the table.
|
|
|
218e99 |
+ * Limit it to 512M, which is 16PB for default cluster and L2 table
|
|
|
218e99 |
+ * size */
|
|
|
218e99 |
+ error_report("L1 size too big");
|
|
|
218e99 |
+ return -EFBIG;
|
|
|
218e99 |
+ }
|
|
|
218e99 |
|
|
|
218e99 |
s->extents = g_realloc(s->extents,
|
|
|
218e99 |
(s->num_extents + 1) * sizeof(VmdkExtent));
|
|
|
218e99 |
@@ -598,14 +606,6 @@ static int vmdk_open_vmdk4(BlockDriverState *bs,
|
|
|
218e99 |
}
|
|
|
218e99 |
l1_size = (le64_to_cpu(header.capacity) + l1_entry_sectors - 1)
|
|
|
218e99 |
/ l1_entry_sectors;
|
|
|
218e99 |
- if (l1_size > 512 * 1024 * 1024) {
|
|
|
218e99 |
- /* although with big capacity and small l1_entry_sectors, we can get a
|
|
|
218e99 |
- * big l1_size, we don't want unbounded value to allocate the table.
|
|
|
218e99 |
- * Limit it to 512M, which is 16PB for default cluster and L2 table
|
|
|
218e99 |
- * size */
|
|
|
218e99 |
- error_report("L1 size too big");
|
|
|
218e99 |
- return -EFBIG;
|
|
|
218e99 |
- }
|
|
|
218e99 |
if (le32_to_cpu(header.flags) & VMDK4_FLAG_RGD) {
|
|
|
218e99 |
l1_backup_offset = le64_to_cpu(header.rgd_offset) << 9;
|
|
|
218e99 |
}
|
|
|
218e99 |
--
|
|
|
218e99 |
1.7.1
|
|
|
218e99 |
|