On 9/23/19 5:38 AM, Paul Durrant wrote:
>> -----Original Message-----
>> From: John Snow <[email protected]>
>> Sent: 20 September 2019 22:11
>> To: Paul Durrant <[email protected]>; [email protected];
>> [email protected];
>> [email protected]
>> Cc: Kevin Wolf <[email protected]>; Stefano Stabellini
>> <[email protected]>; Max Reitz
>> <[email protected]>; Anthony Perard <[email protected]>; Mark Syms
>> <[email protected]>
>> 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 <[email protected]>
