On Thursday 11 April 2013 20:59:05 Ming Lei wrote:
> On Thu, Apr 11, 2013 at 8:28 PM, Oliver Neukum <[email protected]> wrote:
> > On Thursday 11 April 2013 20:11:13 Ming Lei wrote:
> >> On Thu, Apr 11, 2013 at 7:14 PM, Oliver Neukum <[email protected]> wrote:
> >> >
> >> > Sorry, I misunderstood.
> >>
> >> No problem, :-)
> >>
> >> >
> >> > Task A Task B
> >> > queue
> >> >
> >> > queue work
> >> > request a reset
> >> >
> >> > allocate memory and block
> >> > cancel the work
> >> >
> >> > shit happened
> >>
> >> If I understand the case correctly, the above deadlock can be avoided
> >> by canceling rx/tx URBs at the end of pre_reset() or usbnet_disconnect(),
> >
> > No. cancel_work_sync() must wait for the work. The work will not finish.
>
> The work will complete when memory is reclaimed, and the rx/tx path is
> still working, so memory reclaim can continue and the deadlock may not
> be caused, may it?
Only if the memory allocation goes to the same interface. If the blocking
interface
is storage, something bad happens (data loss not deadlock)
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
