[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/2] v2 Fix Block Hotplug race with drive_unplug
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] [PATCH 2/2] v2 Fix Block Hotplug race with drive_unplug() |
Date: |
Thu, 21 Oct 2010 14:27:38 +0100 |
User-agent: |
Mutt/1.4.1i |
On Tue, Oct 19, 2010 at 09:32:29AM -0500, Ryan Harper wrote:
> Block hot unplug is racy since the guest is required to acknowlege the ACPI
> unplug event; this may not happen synchronously with the device removal
> command
>
> This series aims to close a gap where by mgmt applications that assume the
> block resource has been removed without confirming that the guest has
> acknowledged the removal may re-assign the underlying device to a second guest
> leading to data leakage.
>
> This series introduces a new montor command to decouple asynchornous device
> removal from restricting guest access to a block device. We do this by
> creating
> a new monitor command drive_unplug which maps to a bdrv_unplug() command which
> does a qemu_aio_flush; bdrv_flush() and bdrv_close(). Once complete,
> subsequent
> IO is rejected from the device and the guest will get IO errors but continue
> to
> function.
>
> A subsequent device removal command can be issued to remove the device, to
> which
> the guest may or maynot respond, but as long as the unplugged bit is set, no
> IO
> will be sumbitted.
The name 'drive_unplug' suggests to me that the drive object is
not being deleted/free()d ? Is that correct understanding, and if
so, what is responsible for finally free()ing the drive backend ?
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
[Qemu-devel] [PATCH 1/2] v2 Add drive_get_by_id, Ryan Harper, 2010/10/19