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

[Aurelien Chartier <aurelien.chartier@xxxxxxxxxx>]

On 14/05/13 14:38, David Vrabel wrote:
>
>>>> +  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.
>> Yes, that will be blocked until xenstored process has been resumed,
>> since it is the current behavior. However, as the process resume is now
>> happening in parallel, it will only stay blocked for a very short period
>> of time.
> This may cause deadlocks.
>
> It used to be that a work item could block the execution of other work
> on that workqueue by sleeping or not completing,  but workqueues have
> changed quite a bit since I last looked at them detail so this might not
> be the case any more.
>
> As resuming N devices queues N work items this can cause N worker
> threads to block.  Is it guaranteed that the kernel can continue to
> create more workers to handle any work items required before xenstored
> can start?
>
> The safe and obviously correct method would be to create a dedicated
> workqueue for this resume work.

Ok, I get your point. I used a dedicated workqueue in my previous patch
but switched to use schedule_work, since I thought it was not worth
having a dedicated one. I'll switch back to that in the v4.

Thanks,
Aurelien

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel