On 9/18/19 7:57 AM, Paul Durrant wrote:
> When a frontend gracefully disconnects from an offline backend, it will
> set its own state to XenbusStateClosed. The code in xen-block.c correctly
> deals with this and sets the backend into XenbusStateClosed. Unfortunately
> it is possible for toolstack to actually delete the frontend area
> before the state key has been read, leading to an apparent frontend state
> of XenbusStateUnknown. This prevents the backend state from transitioning
> to XenbusStateClosed and hence leaves it limbo.
>
Does the 0 come from a read into de-allocated memory?
--js
> This patch simply treats a frontend state of XenbusStateUnknown the same
> as XenbusStateClosed, which will unblock the backend in these circumstances.
>
> Reported-by: Mark Syms <mark.s...@citrix.com>
> Signed-off-by: Paul Durrant <paul.durr...@citrix.com>
> ---
> Cc: Stefano Stabellini <sstabell...@kernel.org>
> Cc: Anthony Perard <anthony.per...@citrix.com>
> Cc: Kevin Wolf <kw...@redhat.com>
> Cc: Max Reitz <mre...@redhat.com>
> ---
> hw/block/xen-block.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
> index f77343db60..879fc310a4 100644
> --- a/hw/block/xen-block.c
> +++ b/hw/block/xen-block.c
> @@ -313,6 +313,7 @@ static void xen_block_frontend_changed(XenDevice *xendev,
> break;
>
> case XenbusStateClosed:
> + case XenbusStateUnknown:
> xen_block_disconnect(xendev, &local_err);
> if (local_err) {
> error_propagate(errp, local_err);
>
