Re: [GIT] HID

[Ingo Molnar <mingo@kernel.org>]

* Jiri Kosina <jkosina@suse.cz> wrote:

> On Tue, 14 May 2013, Ingo Molnar wrote:
> 
> > > > FYI, there's a new HID related lockdep and RCU splat upstream, probably 
> > > > relatd to the debugfs locking fixes:
> > > > 
> > > > [   79.088631] ======================================================
> > > > [   79.088631] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
> > > > [   79.088631] 3.9.0-13694-g7cf229a-dirty #224212 Tainted: G        W   
> > > > [   79.088631] ------------------------------------------------------
> > > > [   79.088631] swapper/0/1 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
> > > > [   79.088631]  (&hdev->debug_list_lock){+.+...}, at: [<ffffffff82e510d9>] hid_debug_event+0x2e/0xd0
> > > > [   79.088631] 
> > > > 
> > > > See the full bootlog below. It's from an allyesconfig x86-64 bootup log.
> > > 
> > > Hi Ingo,
> > > 
> > > thanks for the report. I have a fix for this in my tree already and am 
> > > going to send pull request to Linus shortly.
> > 
> > FYI, the fixes in your tree apparently did not fix the bug - I'm still 
> > getting the same lockdep splat below.
> 
> Hi Ingo,
> 
> which Linus' git tree topmost commit is that? The lockdep splat seems 
> highly suspicious to me, because:
> 
> [ ... snip ... ]
> > and this task is already holding:
> >  (&(&usbhid->lock)->rlock){-.....}, at: [<c1bc08e4>] usb_hidinput_input_event+0x7c/0xaf
> > which would create a new lock dependency:
> >  (&(&usbhid->lock)->rlock){-.....} -> (&hdev->debug_list_lock){+.+...}
> > 
> > but this new dependency connects a HARDIRQ-irq-safe lock:
> >  (&(&usbhid->lock)->rlock){-.....}
> > ... which became HARDIRQ-irq-safe at:
> >   [<c106974e>] __lock_acquire+0x241/0xd54
> >   [<c106a662>] lock_acquire+0x76/0x8a
> >   [<c1dbe21a>] _raw_spin_lock+0x3d/0x4a
> >   [<c1bc0764>] hid_ctrl+0x28/0x12c
> >   [<c19bfcec>] usb_hcd_giveback_urb+0x40/0x84
> >   [<c19e15cc>] finish_urb+0xbe/0xf4
> >   [<c19e163b>] takeback_td+0x39/0x99
> >   [<c19e1850>] dl_done_list+0x1b5/0x1e4
> >   [<c19e28a1>] ohci_irq+0x16c/0x27a
> >   [<c19bf46d>] usb_hcd_irq+0x26/0x4f
> >   [<c1088cc2>] handle_irq_event_percpu+0x24/0x11f
> >   [<c1088de9>] handle_irq_event+0x2c/0x43
> >   [<c108ad05>] handle_fasteoi_irq+0x6a/0x97
> > 
> > to a HARDIRQ-irq-unsafe lock:
> >  (&hdev->debug_list_lock){+.+...}
> > ... which became HARDIRQ-irq-unsafe at:
> > ...  [<c10697b1>] __lock_acquire+0x2a4/0xd54
> >   [<c106a662>] lock_acquire+0x76/0x8a
> >   [<c1dbc602>] __mutex_lock_common+0x4f/0x36f
> >   [<c1dbc960>] mutex_lock_nested+0x3e/0x44
> >   [<c1ba316b>] hid_debug_event+0x1e/0xa8
> 
> .. this is odd. In current Linus' tree we have
> 
> 	spin_lock_irqsave(&hdev->debug_list_lock, flags);
> 
> in hid_debug_event(), as commit 1deb9d341d turned debug_list_lock from 
> mutex to spinlock, but the trace implies that your kernel is trying to 
> acquire mutex.
> 
> Could you please check that you are running kernel which contains 
> 1deb9d341d? 
> 
> 	$ git describe --contains 1deb9d341d475
> 	v3.10-rc1~13^2
> 
> On Linus' tree.

Indeed, you are right, I was running a few days old kernel on that box. 
Sorry about the noise!

Thanks,

	Ingo