Messages in this thread | | | Date | Wed, 15 May 2013 11:10:21 +0200 | From | Ingo Molnar <> | Subject | Re: [GIT] HID |
| |
* 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
| |