qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/2] Fix Block Hotplug race with drive_unplug()


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH 2/2] Fix Block Hotplug race with drive_unplug()
Date: Tue, 19 Oct 2010 11:45:01 +0100

On Mon, Oct 18, 2010 at 11:17 PM, Ryan Harper <address@hidden> 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 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.
>
> Signed-off-by: Ryan Harper <address@hidden>
> ---
>  block.c         |    6 ++++++
>  block.h         |    1 +
>  blockdev.c      |   26 ++++++++++++++++++++++++++
>  blockdev.h      |    1 +
>  hmp-commands.hx |   15 +++++++++++++++
>  5 files changed, 49 insertions(+), 0 deletions(-)
>
> diff --git a/block.c b/block.c
> index a19374d..9fedb27 100644
> --- a/block.c
> +++ b/block.c
> @@ -1328,6 +1328,12 @@ void bdrv_set_removable(BlockDriverState *bs, int 
> removable)
>     }
>  }
>
> +void bdrv_unplug(BlockDriverState *bs)
> +{
> +    bdrv_flush(bs);
> +    bdrv_close(bs);

bdrv_flush() does not wait for pending aio requests to complete.
bdrv_close() does not wait either.

A VM with a qcow2 image file and pending aio requests could
bdrv_unplug() and free the qcow2 state before aio completions occur.
If a completion is handled after bdrv_close(), the qcow2 in-memory
state has been freed and we get memory corruption or a crash.

I think the solution is to use qemu_aio_flush() before bdrv_flush().
I waits until all pending aio requests have been completed.

Stefan



reply via email to

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