On 9/23/19 5:38 AM, Paul Durrant wrote:
>> -----Original Message-----
>> From: John Snow <js...@redhat.com>
>> Sent: 20 September 2019 22:11
>> To: Paul Durrant <paul.durr...@citrix.com>; xen-de...@lists.xenproject.org;
>> qemu-devel@nongnu.org;
>> qemu-bl...@nongnu.org
>> Cc: Kevin Wolf <kw...@redhat.com>; Stefano Stabellini
>> <sstabell...@kernel.org>; Max Reitz
>> <mre...@redhat.com>; Anthony Perard <anthony.per...@citrix.com>; Mark Syms
>> <mark.s...@citrix.com>
>> 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 <js...@redhat.com>
