On Tuesday 11 June 2013 17:27:28 Ming Lei wrote:

On Tue, Jun 11, 2013 at 4:49 PM, Oliver Neukum [off-list ref] wrote:

quoted

On Tuesday 11 June 2013 16:14:25 Ming Lei wrote:

quoted

The driver itself may have submitted a timer and race against it.
What locking do you need in complete() and a timer to lock against
each other?

Good catch.

The problem will come if only spin_lock() is called inside complete(),
I will check main USB drivers in tree to see if there is such use case.

All network drivers race against timeout. I think they just unlink the URB,
but there's a lot of them.

quoted

But it makes no sense to go to a tasklet when you are already in task context.
In those cases you need to do something, essentially blocking the tasklet.

At least now, always doing complete() in tasklet handler can simplify
implementation since these cases aren't in hot path.

Well, I am afraid this is not simply the case. These cases are partially
synchronous. For example you need to make sure all calls to complete()
are finished before you disconnect a HCD itself. The same applies to a device
being disconnected.

It the same area, what happens if an URB is unlinked between the irq handler
and the tasklet?

	Regards
		Oliver