Re: Spinlock recursion in usbnet + rndis-wlan

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am Saturday 17 January 2009 23:44:12 schrieb David Brownell:
> On Saturday 17 January 2009, Oliver Neukum wrote:
> > 
> > > What HCD change(s) were you thinking of?
> > 
> > HCDs shall not call the completion handler from the context that
> > called usb_submit_urb(), if necessary from a workqueue.
> 
> That wouldn't address $SUBJECT **at all** ... the issue is
> calling completions from the context issuing usb_unlink_urb().

Yes, you are right. ALthough the same problem arises.

> Phasing in such a context restriction could be problematic,
> and of course there's the issue of actually getting and testing
> patches for all the relevant HCDs.  Could usbcore at least
> detect that an HCD isn't adhering to such new rule?

Is it really new? It seems to me the behavior was never defined,
but the big three behave this way.
 
> There's a complementary issue ... a completion callback may
> call usb_unlink_urb().  I'd have to think more about that,
> but be very cautious about changing _those_ semantics.  On
> fault paths, a completion callback must be able to unlink
> every URB in the queue for its endpoint, without letting
> any of them hit the hardware.

Yes.

> Last time I thought about this issue, I kept thinking that
> what's *really* needed is getting rid of one-at-a-time
> semantics for unlinking URBs ... and replacing them with
> "unlink everything queued to this endpoint" semantics.

Endpoint 0 is shared. You cannot let one driver massacre
everything.

> I don't recall even one case where "dequeue just one URB"
> was really the desired usage model.  It's a leftover from
> the early USB work for the Linux 2.2.8+ kernel.
> 
> 
> > Do you know which HCDs are affected?
> 
> The unlinking issue generally applies to any HCD that
> doesn't have to disable hardware queues to unlink.
> It's the "disable queue" which forces a contex switch
> on stuff like EHCI/OHCI/UHCI, so they don't see $SUBJECT.
> 
> Right off the top of my head:  sl811_hc and musb_hdrc
> both have purely software queues, and can (do!) process
> unlinks immediatly.  Plus there's the HCD associated
> with the $SUBJECT bug report ... ISTR seeing a comment
> from Jeremy about other affected HCDs.

OK, if we are talking API changes, do we really want a callback
if the hardware never saw an URB?

	Regards
		Oliver



--
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

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux