xen-block: treat XenbusStateUnknown the same as XenbusStateClosed

Commit Message

Paul Durrant Sept. 18, 2019, 11:57 a.m. UTC

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.

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 <[e-mail]>
Signed-off-by: Paul Durrant <[e-mail]>
---
Cc: Stefano Stabellini <[e-mail]>
Cc: Anthony Perard <[e-mail]>
Cc: Kevin Wolf <[e-mail]>
Cc: Max Reitz <[e-mail]>
---
 hw/block/xen-block.c | 1 +
 1 file changed, 1 insertion(+)

Comments

John Snow Sept. 20, 2019, 9:10 p.m. UTC | #1

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 <[e-mail]>
> Signed-off-by: Paul Durrant <[e-mail]>
> ---
> Cc: Stefano Stabellini <[e-mail]>
> Cc: Anthony Perard <[e-mail]>
> Cc: Kevin Wolf <[e-mail]>
> Cc: Max Reitz <[e-mail]>
> ---
>  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);
>

Paul Durrant Sept. 23, 2019, 9:38 a.m. UTC | #2

> -----Original Message-----
> From: John Snow <[e-mail]>
> Sent: 20 September 2019 22:11
> To: Paul Durrant <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]
> Cc: Kevin Wolf <[e-mail]>; Stefano Stabellini <[e-mail]>; Max Reitz
> <[e-mail]>; Anthony Perard <[e-mail]>; Mark Syms <[e-mail]>
> Subject: Re: [Qemu-block] [PATCH] xen-block: treat XenbusStateUnknown the same as XenbusStateClosed
> 
> 
> 
> 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?

No, it comes from the fact that the xenstore state key is not present. Conventionally a missing state key means the state is reported as XenbusStateUnknown.

  Paul

> 
> --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 <[e-mail]>
> > Signed-off-by: Paul Durrant <[e-mail]>
> > ---
> > Cc: Stefano Stabellini <[e-mail]>
> > Cc: Anthony Perard <[e-mail]>
> > Cc: Kevin Wolf <[e-mail]>
> > Cc: Max Reitz <[e-mail]>
> > ---
> >  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);
> >

Anthony PERARD Sept. 23, 2019, 11:34 a.m. UTC | #3

On Wed, Sep 18, 2019 at 12:57:02PM +0100, 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.
> 
> 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 <[e-mail]>
> Signed-off-by: Paul Durrant <[e-mail]>

Acked-by: Anthony PERARD <[e-mail]>

Thanks,

John Snow Sept. 23, 2019, 5:08 p.m. UTC | #4

On 9/23/19 5:38 AM, Paul Durrant wrote:
>> -----Original Message-----
>> From: John Snow <[e-mail]>
>> Sent: 20 September 2019 22:11
>> To: Paul Durrant <[e-mail]>; [e-mail]; [e-mail];
>> [e-mail]
>> Cc: Kevin Wolf <[e-mail]>; Stefano Stabellini <[e-mail]>; Max Reitz
>> <[e-mail]>; Anthony Perard <[e-mail]>; Mark Syms <[e-mail]>
>> Subject: Re: [Qemu-block] [PATCH] xen-block: treat XenbusStateUnknown the same as XenbusStateClosed
>>
>>
>>
>> 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?
> 
> No, it comes from the fact that the xenstore state key is not present. Conventionally a missing state key means the state is reported as XenbusStateUnknown.
> 
>   Paul
> 

Good enough for me, just had to confirm.

Reviewed-by: John Snow <[e-mail]>

Patch

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);