Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965216AbWHOGgv (ORCPT ); Tue, 15 Aug 2006 02:36:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965217AbWHOGgv (ORCPT ); Tue, 15 Aug 2006 02:36:51 -0400 Received: from smtp.osdl.org ([65.172.181.4]:50335 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S965216AbWHOGgu (ORCPT ); Tue, 15 Aug 2006 02:36:50 -0400 Date: Mon, 14 Aug 2006 23:36:26 -0700 From: Andrew Morton To: Dave Jones Cc: Linux Kernel , Arjan van de Ven , Ingo Molnar Subject: Re: workqueue lockdep bug. Message-Id: <20060814233626.1e3c41b2.akpm@osdl.org> In-Reply-To: <20060814183319.GJ15569@redhat.com> References: <20060814183319.GJ15569@redhat.com> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.17; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4409 Lines: 115 On Mon, 14 Aug 2006 14:33:19 -0400 Dave Jones wrote: > Andrew, > I merged the workqueue changes from -mm into the Fedora-devel kernel to > kill off those billion cpufreq lockdep warnings. The bug has now mutated > into this: > > (Trimmed version of log from https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202223) > I don't get it. > > > Breaking affinity for irq 185 > > Breaking affinity for irq 193 > > Breaking affinity for irq 209 > > CPU 1 is now offline > > lockdep: not fixing up alternatives. > > > > ======================================================= > > [ INFO: possible circular locking dependency detected ] > > 2.6.17-1.2548.fc6 #1 > > ------------------------------------------------------- > > pm-hibernate/4335 is trying to acquire lock: > > ((cpu_chain).rwsem){..--}, at: [] blocking_notifier_call_chain+0x11/0x2d > > > > but task is already holding lock: > > (workqueue_mutex){--..}, at: [] mutex_lock+0x21/0x24 > > > > which lock already depends on the new lock. > > > > > > the existing dependency chain (in reverse order) is: > > > > -> #1 (workqueue_mutex){--..}: > > [] lock_acquire+0x4b/0x6d > > [] __mutex_lock_slowpath+0xbc/0x20a > > [] mutex_lock+0x21/0x24 > > [] workqueue_cpu_callback+0xfd/0x1ee > > [] notifier_call_chain+0x20/0x31 > > [] blocking_notifier_call_chain+0x1d/0x2d > > [] _cpu_down+0x47/0x1c4 > > [] disable_nonboot_cpus+0x9b/0x11a > > [] prepare_processes+0xe/0x41 > > [] pm_suspend_disk+0x9/0xf3 > > [] enter_state+0x54/0x1b7 > > [] state_store+0x86/0x9c > > [] subsys_attr_store+0x20/0x25 > > [] sysfs_write_file+0xab/0xd1 > > [] vfs_write+0xab/0x157 > > [] sys_write+0x3b/0x60 > > [] syscall_call+0x7/0xb cpu_add_remove_lock -> cpu_chain.rwsem -> workqueue_mutex > > -> #0 ((cpu_chain).rwsem){..--}: > > [] lock_acquire+0x4b/0x6d > > [] down_read+0x2d/0x40 > > [] blocking_notifier_call_chain+0x11/0x2d > > [] _cpu_down+0x12c/0x1c4 > > [] disable_nonboot_cpus+0x9b/0x11a > > [] prepare_processes+0xe/0x41 > > [] pm_suspend_disk+0x9/0xf3 > > [] enter_state+0x54/0x1b7 > > [] state_store+0x86/0x9c > > [] subsys_attr_store+0x20/0x25 > > [] sysfs_write_file+0xab/0xd1 > > [] vfs_write+0xab/0x157 > > [] sys_write+0x3b/0x60 > > [] syscall_call+0x7/0xb cpu_add_remove_lock -> cpu_chain.rwsem > > other info that might help us debug this: > > > > 2 locks held by pm-hibernate/4335: > > #0: (cpu_add_remove_lock){--..}, at: [] mutex_lock+0x21/0x24 > > #1: (workqueue_mutex){--..}, at: [] mutex_lock+0x21/0x24 > > > > stack backtrace: > > [] show_trace_log_lvl+0x58/0x159 > > [] show_trace+0xd/0x10 > > [] dump_stack+0x19/0x1b > > [] print_circular_bug_tail+0x59/0x64 > > [] __lock_acquire+0x80d/0x99c > > [] lock_acquire+0x4b/0x6d > > [] down_read+0x2d/0x40 > > [] blocking_notifier_call_chain+0x11/0x2d > > [] _cpu_down+0x12c/0x1c4 > > [] disable_nonboot_cpus+0x9b/0x11a > > [] prepare_processes+0xe/0x41 > > [] pm_suspend_disk+0x9/0xf3 > > [] enter_state+0x54/0x1b7 > > [] state_store+0x86/0x9c > > [] subsys_attr_store+0x20/0x25 > > [] sysfs_write_file+0xab/0xd1 > > [] vfs_write+0xab/0x157 > > [] sys_write+0x3b/0x60 > > [] syscall_call+0x7/0xb cpu_add_remove_lock -> cpu_chain.rwsem I don't see anywhere where this process took workqueue_mutex. > > DWARF2 unwinder stuck at syscall_call+0x7/0xb bah. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/