linux-kernel - Re: [GIT] HID

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.2.00.1305142319310.17873@pobox.suse.cz>
Date:	Tue, 14 May 2013 23:23:39 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [GIT] HID

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/