Re: [GIT] HID

[Jiri Kosina]

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.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/