Bug#670398: Deadlock in hid_reset when Dell iDRAC is reset

[<Stuart_Hayes@Dell.com>]

> 
> On Sun, Jul 15, 2012 at 11:41:33PM +0100, Ben Hutchings wrote:
> 
> Hi,
> 
> > I assume you mean this patch:
> > <http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=65;filename=0001-
> usb-Fix-deadlock-in-hid_reset-when-Dell-iDRAC.patch;att=1;bug=670398>
> > so I'll apply that.
> 
> Exactly, that would be great.
> 
> 
> > It won't be accepted into a 2.6.32.y release unless someone can
> explain
> > how it was fixed upstream (ideally, which commit(s) fixed it).
> 
> I think it was somewhere mentioned that it got fixed with some USB-HID
> rewrite
> in 2.6.36 or 2.6.37. We could not reproduce it with Linux 3.2 from
> backports
> and internal builds of 2.6.37. But I can see that this isn't a proper
> explanation or reason for an inclusion upstream.
> 
> Sven
> 

I believe this was fixed with changes to the kernel workqueue code (in 2.6.36, I believe).

In older kernels, the kernel workqueue would run one queued item at a time, and wait for it to finish before running the next one.  The function hid_reset() is running on keventd (the workqueue).  When a transaction run by hid_reset() gets a timeout trying to talk to the iDRAC, it puts hub_tt_work() on the workqueue to be run by keventd (by calling schedule_work(&tt->clear_work)) and waits for it to finish.  But keventd is waiting for hid_reset() to finish before it will run hub_tt_work().  So deadlock.

Later kernels don't wait for each item on the workqueue to finish before starting the next, as I recall.

Stuart