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-devel@lists.xenproject.org; >> qemu-de...@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> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
