Re: [PATCH V3 2/2] xenbus: delay xenbus frontend resume is xenstored is not running

[David Vrabel <david.vrabel@citrix.com>]

On 13/05/13 14:13, Aurelien Chartier wrote:
> If the xenbus frontend is located in a domain running xenstored, the device
> resume is hanging because it is happening before the process resume. This
> patch adds extra logic to the resume code to check if we are the domain
> running xenstored and delay the resume if needed.

Would this be better done at the bus level instead of per-device?

> --- a/drivers/xen/xenbus/xenbus_probe_frontend.c
> +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
> @@ -89,9 +89,33 @@ static void backend_changed(struct xenbus_watch *watch,
>  	xenbus_otherend_changed(watch, vec, len, 1);
>  }
>  
> +static void xenbus_frontend_delayed_resume(struct work_struct *w)
> +{
> +	struct xenbus_device *xdev = container_of(w, struct xenbus_device, work);
> +
> +	xenbus_dev_resume(&xdev->dev);
> +}
> +
> +static int xenbus_frontend_dev_resume(struct device *dev)
> +{
> +	/* 
> +	 * If xenstored is running in that domain, we cannot access the backend
> +	 * state at the moment, so we need to defer xenbus_dev_resume
> +	 */

I think you mean "If xenstored is running in /this/ domain, we cannot
access the backend state at the moment..."

> +	if (xen_store_domain == XS_LOCAL) {
> +		struct xenbus_device *xdev = to_xenbus_device(dev);
> +
> +		INIT_WORK(&xdev->work, xenbus_frontend_delayed_resume);
> +		schedule_work(&xdev->work);

How does this ensure xenstored is running when the work is scheduled?
Will it end up blocking on a system workqueue until xenstored is
running?  That would be bad.

David