On 04-08-16, 11:20, Alan Stern wrote:
> Yes, it could lead to this deadlock.
>
> > Should we rather have device_trylock instead of device_lock
>
> No.
>
> > > @@ -1031,10 +1031,20 @@ static void hub_activate(struct usb_hub
> > > unsigned delay;
> > >
> > > /* Continue a partial initialization */
> > > - if (type == HUB_INIT2)
> > > - goto init2;
> > > - if (type == HUB_INIT3)
> > > + if (type == HUB_INIT2 || type == HUB_INIT3) {
> > > + device_lock(hub->intfdev);
> >
> > device_trylock?? If failed to acquire then treat that as disconnect?
>
> No, that's not the right answer. I believe the correct solution is to
> remove the cancel_delayed_work_sync() call in hub_quiesce().
>
> Viresh, do you agree?
Hmm, so I think we have two different problems here and maybe we should fix them
separately. But surely, my patch isn't enough and we need to do it the way you
suggested, i.e. let the work die by itself.
What about another patch on top of my patch to fix the deadlock?
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
