From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758038Ab3EOJK3 (ORCPT ); Wed, 15 May 2013 05:10:29 -0400 Received: from mail-ee0-f53.google.com ([74.125.83.53]:41487 "EHLO mail-ee0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754811Ab3EOJKY (ORCPT ); Wed, 15 May 2013 05:10:24 -0400 Date: Wed, 15 May 2013 11:10:21 +0200 From: Ingo Molnar To: Jiri Kosina Cc: Linus Torvalds , linux-kernel@vger.kernel.org Subject: Re: [GIT] HID Message-ID: <20130515091020.GA6819@gmail.com> References: <20130510114759.GA19857@gmail.com> <20130514183108.GA4904@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Jiri Kosina 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: [] 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: [] 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: > > [] __lock_acquire+0x241/0xd54 > > [] lock_acquire+0x76/0x8a > > [] _raw_spin_lock+0x3d/0x4a > > [] hid_ctrl+0x28/0x12c > > [] usb_hcd_giveback_urb+0x40/0x84 > > [] finish_urb+0xbe/0xf4 > > [] takeback_td+0x39/0x99 > > [] dl_done_list+0x1b5/0x1e4 > > [] ohci_irq+0x16c/0x27a > > [] usb_hcd_irq+0x26/0x4f > > [] handle_irq_event_percpu+0x24/0x11f > > [] handle_irq_event+0x2c/0x43 > > [] handle_fasteoi_irq+0x6a/0x97 > > > > to a HARDIRQ-irq-unsafe lock: > > (&hdev->debug_list_lock){+.+...} > > ... which became HARDIRQ-irq-unsafe at: > > ... [] __lock_acquire+0x2a4/0xd54 > > [] lock_acquire+0x76/0x8a > > [] __mutex_lock_common+0x4f/0x36f > > [] mutex_lock_nested+0x3e/0x44 > > [] 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