From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756885Ab0JOUIw (ORCPT ); Fri, 15 Oct 2010 16:08:52 -0400 Received: from einhorn.in-berlin.de ([192.109.42.8]:41010 "EHLO einhorn.in-berlin.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756871Ab0JOUIu (ORCPT ); Fri, 15 Oct 2010 16:08:50 -0400 X-Envelope-From: stefanr@s5r6.in-berlin.de Date: Fri, 15 Oct 2010 22:08:33 +0200 (CEST) From: Stefan Richter Subject: cpufreq: circular lock dependency To: cpufreq@vger.kernel.org cc: Dave Jones , linux-kernel@vger.kernel.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Google says this is an old bug. Got it today when I switched from ondemand to performance by # echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor for each of cpu0,1,2,3. ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.36-rc7 #8 ------------------------------------------------------- cpufreq-hi/11879 is trying to acquire lock: (s_active#93){++++.+}, at: [] sysfs_hash_and_remove+0x53/0x77 but task is already holding lock: (dbs_mutex){+.+.+.}, at: [] cpufreq_governor_dbs+0x372/0x423 [cpufreq_ondemand] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (dbs_mutex){+.+.+.}: [] lock_acquire+0x5a/0x71 [] mutex_lock_nested+0x5c/0x2fa [] cpufreq_governor_dbs+0x7e/0x423 [cpufreq_ondemand] [] __cpufreq_governor+0xaa/0xe7 [] __cpufreq_set_policy+0x104/0x142 [] store_scaling_governor+0x185/0x1c5 [] store+0x5f/0x84 [] sysfs_write_file+0xf1/0x126 [] vfs_write+0xae/0x135 [] sys_write+0x47/0x6e [] system_call_fastpath+0x16/0x1b -> #1 (&per_cpu(cpu_policy_rwsem, cpu)){+.+.+.}: [] lock_acquire+0x5a/0x71 [] down_write+0x3f/0x60 [] lock_policy_rwsem_write+0x48/0x78 [] store+0x40/0x84 [] sysfs_write_file+0xf1/0x126 [] vfs_write+0xae/0x135 [] sys_write+0x47/0x6e [] system_call_fastpath+0x16/0x1b -> #0 (s_active#93){++++.+}: [] __lock_acquire+0x1169/0x182c [] lock_acquire+0x5a/0x71 [] sysfs_addrm_finish+0xd0/0x13f [] sysfs_hash_and_remove+0x53/0x77 [] sysfs_remove_group+0x90/0xc8 [] cpufreq_governor_dbs+0x389/0x423 [cpufreq_ondemand] [] __cpufreq_governor+0xaa/0xe7 [] __cpufreq_set_policy+0xee/0x142 [] store_scaling_governor+0x185/0x1c5 [] store+0x5f/0x84 [] sysfs_write_file+0xf1/0x126 [] vfs_write+0xae/0x135 [] sys_write+0x47/0x6e [] system_call_fastpath+0x16/0x1b other info that might help us debug this: 4 locks held by cpufreq-hi/11879: #0: (&buffer->mutex){+.+.+.}, at: [] sysfs_write_file+0x39/0x126 #1: (s_active#92){.+.+.+}, at: [] sysfs_write_file+0xd6/0x126 #2: (&per_cpu(cpu_policy_rwsem, cpu)){+.+.+.}, at: [] lock_policy_rwsem_write+0x48/0x78 #3: (dbs_mutex){+.+.+.}, at: [] cpufreq_governor_dbs+0x372/0x423 [cpufreq_ondemand] stack backtrace: Pid: 11879, comm: cpufreq-hi Not tainted 2.6.36-rc7 #8 Call Trace: [] print_circular_bug+0xb3/0xc2 [] __lock_acquire+0x1169/0x182c [] ? get_parent_ip+0x11/0x42 [] ? lockdep_init_map+0x9f/0x4fe [] lock_acquire+0x5a/0x71 [] ? sysfs_hash_and_remove+0x53/0x77 [] ? __init_waitqueue_head+0x35/0x48 [] sysfs_addrm_finish+0xd0/0x13f [] ? sysfs_hash_and_remove+0x53/0x77 [] ? mutex_lock_nested+0x2a3/0x2fa [] ? mark_held_locks+0x4d/0x6b [] sysfs_hash_and_remove+0x53/0x77 [] sysfs_remove_group+0x90/0xc8 [] cpufreq_governor_dbs+0x389/0x423 [cpufreq_ondemand] [] ? up_read+0x1e/0x38 [] ? get_parent_ip+0x11/0x42 [] __cpufreq_governor+0xaa/0xe7 [] __cpufreq_set_policy+0xee/0x142 [] store_scaling_governor+0x185/0x1c5 [] ? handle_update+0x0/0xe [] ? down_write+0x3f/0x60 [] store+0x5f/0x84 [] sysfs_write_file+0xf1/0x126 [] vfs_write+0xae/0x135 [] sys_write+0x47/0x6e [] system_call_fastpath+0x16/0x1b -- Stefan Richter -=====-==-=- =-=- -==== http://arcgraph.de/sr/