qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

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