[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/1] block/vpc.c: Detect too-large vpc file
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH 1/1] block/vpc.c: Detect too-large vpc file |
Date: |
Tue, 26 Jul 2011 11:01:09 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110707 Thunderbird/5.0 |
Am 25.07.2011 20:34, schrieb Serge E. Hallyn:
> VHD files technically can be up to 2Tb, but virtual pc is limited
> to 127G. Currently qemu-img refused to create vpc files > 127G,
> but it is failing to return error when converting from a non-vpc
> VHD file which is >127G. It returns success, but creates a truncated
> converted image. Also, qemu-img info claims the vpc file is 127G
> (and clean).
>
> This patch detects a too-large vpc file and returns -EFBIG. Without
> this patch,
>
> =============================================================
> address@hidden:~/qemu-fixed# qemu-img info /mnt/140g-dynamic.vhd
> image: /mnt/140g-dynamic.vhd
> file format: vpc
> virtual size: 127G (136899993600 bytes)
> disk size: 284K
> address@hidden:~/qemu-fixed# qemu-img convert -f vpc -O raw
> /mnt/140g-dynamic.vhd /mnt/y
> address@hidden:~/qemu-fixed# echo $?
> 0
> address@hidden:~/qemu-fixed# qemu-img info /mnt/y
> image: /mnt/y
> file format: raw
> virtual size: 127G (136899993600 bytes)
> disk size: 0
> =============================================================
>
> (The 140G image was truncated with no warning or error.)
>
> With the patch, I get:
>
> =============================================================
> address@hidden:~/qemu-fixed# ./qemu-img info /mnt/140g-dynamic.vhd
> qemu-img: Could not open '/mnt/140g-dynamic.vhd': File too large
> address@hidden:~/qemu-fixed# ./qemu-img convert -f vpc -O raw
> /mnt/140g-dynamic.vhd /mnt/y
> qemu-img: Could not open '/mnt/140g-dynamic.vhd': File too large
> qemu-img: Could not open '/mnt/140g-dynamic.vhd'
> =============================================================
>
> See https://bugs.launchpad.net/qemu/+bug/814222 for details.
>
> Signed-off-by: Serge Hallyn <address@hidden>
> ---
> block/vpc.c | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/block/vpc.c b/block/vpc.c
> index 56865da..fdd5236 100644
> --- a/block/vpc.c
> +++ b/block/vpc.c
> @@ -156,6 +156,7 @@ static int vpc_open(BlockDriverState *bs, int flags)
> struct vhd_dyndisk_header* dyndisk_header;
> uint8_t buf[HEADER_SIZE];
> uint32_t checksum;
> + int err = -1;
>
> if (bdrv_pread(bs->file, 0, s->footer_buf, HEADER_SIZE) != HEADER_SIZE)
> goto fail;
> @@ -176,6 +177,11 @@ static int vpc_open(BlockDriverState *bs, int flags)
> bs->total_sectors = (int64_t)
> be16_to_cpu(footer->cyls) * footer->heads * footer->secs_per_cyl;
>
> + if (bs->total_sectors >= 65535 * 16 * 255) {
> + err = -EFBIG;
> + goto fail;
> + }
I wonder why this works. If bs->total_sectors was right, shouldn't it
have converted the full 140 GB? I can't see where else we would limit it
to 127 GB, so what I had expected is that the CHS geometry stored in the
image header is already too small.
What is the CHS geometry of this 140 GB image?
Kevin