qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] file-posix: Check effective size in truncate op


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH] file-posix: Check effective size in truncate operation
Date: Mon, 14 Jan 2019 11:46:34 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 26.11.18 04:57, zhenwei pi wrote:
> Function raw_co_truncate does not check effective size for BLK device file,
> and QEMU may notify guest without any size changing.
> 
> Two cases can be reproduced easily by qmp command:
> CASE 1:
> 1, create a logical volume(12M) by LVM, and guest uses this volume as "vdb"
> 2, run qmp command : virsh qemu-monitor-command INSTANCE '{"execute":
> "block_resize", "arguments":{"device":"drive-virtio-disk1","size":12582912}}'
> 
> The effective size(12M) is equal to the argument(12M) and the real device file
> size(12M). QEMU should ignore this command and has no need to notify guest.

I don't quite see the issue here.  The command is valid, why would it be
an error?  And I don't see the harm in notifying the guest either.

> CASE 2:
> 1, create a logical volume(12M) by LVM, and guest uses this volume as "vdb"
> 2, resize LV to 16M by lvresize command
> 3, run qmp command : virsh qemu-monitor-command INSTANCE '{"execute":
> "block_resize", "arguments":{"device":"drive-virtio-disk1","size":10485760}}'
> 
> The device file size actually grew, but the argument(10M) is less than the
> effective size(12M). This command should fail, but QEMU still report success.

Nor do I see a real problem here.  It isn't dangerous if qemu trusts the
user, but it may break existing use cases to error out if the user
specifies a length that's too short.

In fact, I would suppose if you want to shrink an LVM volume, the
correct way to do it is to first shrink the virtual device in qemu (with
block_resize), and only then shrink the physical device on the host;
otherwise, qemu might issue requests beyond the end of the physical
disk.  This change would break that.

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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