From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Subject: Re: 2.6.33-mmotm0304 - lockdep warning in ACPI code Date: Thu, 18 Mar 2010 13:42:35 -0700 Message-ID: <20100318204235.GA30051@kroah.com> References: <5057.1268124370@localhost> <20100318133658.80a15736.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from kroah.org ([198.145.64.141]:54235 "EHLO coco.kroah.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751261Ab0CRUmi (ORCPT ); Thu, 18 Mar 2010 16:42:38 -0400 Content-Disposition: inline In-Reply-To: <20100318133658.80a15736.akpm@linux-foundation.org> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Andrew Morton Cc: Valdis.Kletnieks@vt.edu, Len Brown , Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, Thomas Gleixner On Thu, Mar 18, 2010 at 01:36:58PM -0700, Andrew Morton wrote: > On Tue, 09 Mar 2010 03:46:10 -0500 > Valdis.Kletnieks@vt.edu wrote: > > > Seen in my dmesg. Appears to have started in 2.6.33-rc7-mmotm0210, I can't > > remember if I reported it before or not... > > > > [ 0.212297] ACPI: Using IOAPIC for interrupt routing > > [ 0.340075] > > [ 0.340076] ============================================= > > [ 0.340241] [ INFO: possible recursive locking detected ] > > [ 0.340330] 2.6.33-mmotm0304 #5 > > [ 0.340415] --------------------------------------------- > > [ 0.340504] swapper/1 is trying to acquire lock: > > [ 0.340591] (&dev->mutex){+.+...}, at: [] __driver_attach+0x47/0x80 > > [ 0.340926] > > [ 0.340927] but task is already holding lock: > > [ 0.340999] (&dev->mutex){+.+...}, at: [] __driver_attach+0x39/0x80 > > [ 0.340999] > > [ 0.340999] other info that might help us debug this: > > [ 0.340999] 1 lock held by swapper/1: > > [ 0.340999] #0: (&dev->mutex){+.+...}, at: [] __driver_attach+0x39/0x80 > > [ 0.340999] > > [ 0.340999] stack backtrace: > > [ 0.340999] Pid: 1, comm: swapper Not tainted 2.6.33-mmotm0304 #5 > > [ 0.340999] Call Trace: > > [ 0.340999] [] __lock_acquire+0xc74/0xceb > > [ 0.340999] [] ? mark_lock+0x2d/0x22c > > [ 0.340999] [] ? __driver_attach+0x47/0x80 > > [ 0.340999] [] lock_acquire+0xf5/0x112 > > [ 0.340999] [] ? __driver_attach+0x47/0x80 > > [ 0.340999] [] ? mark_held_locks+0x52/0x70 > > [ 0.340999] [] __mutex_lock_common+0x5c/0x5aa > > [ 0.340999] [] ? __driver_attach+0x47/0x80 > > [ 0.340999] [] ? klist_next+0x24/0xd7 > > [ 0.340999] [] ? __driver_attach+0x47/0x80 > > [ 0.340999] [] ? __driver_attach+0x0/0x80 > > [ 0.340999] [] mutex_lock_nested+0x34/0x39 > > [ 0.340999] [] __driver_attach+0x47/0x80 > > [ 0.340999] [] ? __driver_attach+0x0/0x80 > > [ 0.340999] [] ? __driver_attach+0x0/0x80 > > [ 0.340999] [] bus_for_each_dev+0x54/0x89 > > [ 0.340999] [] driver_attach+0x19/0x1b > > [ 0.340999] [] bus_add_driver+0xb4/0x203 > > [ 0.340999] [] driver_register+0xb8/0x129 > > [ 0.340999] [] acpi_bus_register_driver+0x3e/0x40 > > [ 0.340999] [] acpi_ec_init+0x37/0x55 > > [ 0.340999] [] acpi_init+0x101/0x116 > > [ 0.340999] [] ? acpi_init+0x0/0x116 > > [ 0.340999] [] do_one_initcall+0x59/0x14e > > [ 0.340999] [] kernel_init+0x14d/0x1d7 > > [ 0.340999] [] kernel_thread_helper+0x4/0x10 > > [ 0.340999] [] ? restore_args+0x0/0x30 > > [ 0.340999] [] ? kernel_init+0x0/0x1d7 > > [ 0.340999] [] ? kernel_thread_helper+0x0/0x10 > > [ 0.341046] ACPI: EC: GPE = 0x11, I/O: command/status = 0x934, data = 0x930 > > > > > > In the future, we are going to be changing the lock type for struct > device (once we get the lockdep infrastructure properly worked out) > > sem to mutex"> > > Seems that the latter patch (from Greg and Thomas) went and did the > mutex conversion before "we got the lockdep infrastructure properly > worked out". Peter and Thomas have a lockdep patch that resolves this, I thought it was going in through one of their trees, but in talking with them yesterday, I was wrong. I will be adding the patch to my tree, right before the "convert to mutex" patch, so this will not show up in the future. thanks, greg k-h