[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2] libxl: do not fail device removal if backend domain is gone



On Fri, Feb 23, 2018 at 09:00:41PM +0100, Marek Marczykowski-Górecki wrote:
> Backend domain may be independently destroyed - there is no
> synchronization of libxl structures (including /libxl tree) elsewhere.
> Backend might also remove the device info from its backend xenstore
> subtree on its own.
> 
> We have various cases (not comprehensive list):
> 
>  - both frontend and backend operational: after setting
>    be/state=XenbusStateClosing backend wait for frontend confirmation
>    and respond with be/state=XenbusStateClosed; then libxl in dom0
>    remove frontend entries and libxl in backend domain (which may be the
>    same) remove backend entries
>  - unresponsive backend/frontend: after a timeout, force=1 is used to remove
>    frontend entries, instead of just setting
>    be/state=XenbusStateClosing; then wait for be/state=XenbusStateClosed.
>    If that timeout too, remove both frontend and backend entries
>  - backend gone, with this patch: no place for setting/waiting on
>    be/state - go directly to removing frontend entries, without waiting
>    for be/state=XenbusStateClosed (this is the difference vs force=1)
> 
> Without this patch the end result is similar, both frontend and backend
> entries are removed, but in case of backend gone:
>  - libxl waits for be/state=XenbusStateClosed (and obviously timeout)
>  - return value from the function signal an error, which for example
>    confuse libvirt - it thinks the device remove failed, so is still
>    there
> 
> If such situation is detected, do not fail the removal, but finish the
> cleanup of the frontend side and return 0.
> 
> This is just workaround, the real fix should watch when the device
> backend is removed (including backend domain destruction) and remove
> frontend at that time. And report such event to higher layer code, so
> for example libvirt could synchronize its state.
> 
> Signed-off-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>

You seem to have dropped my RB:

Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.