lockdep

Jay Cliburn jacliburn at bellsouth.net
Fri Jul 14 17:16:23 UTC 2006


On Fri, 2006-07-14 at 06:58 -0500, Jay Cliburn wrote:
> [jcliburn at osprey ~]$ uname -rm
> 2.6.17-1.2391.fc6 x86_64
> 
> After updating FC6T1 in the past 12 hours, I see the following lockdep
> message.
> 
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> -------------------------------------------------------
> cpuspeed/1527 is trying to acquire lock:
>  (&policy->lock){--..}, at: [<ffffffff802681da>] mutex_lock+0x2a/0x2e
> 
> but task is already holding lock:
>  (cpucontrol){--..}, at: [<ffffffff802681da>] mutex_lock+0x2a/0x2e
> 
<snip>

After today's rawhide kernel update, the same lockdep shows up.  Should
I be filing a BZ on these?

[jcliburn at osprey ~]$ uname -rm
2.6.17-1.2396.fc6 x86_64




=======================================================
[ INFO: possible circular locking dependency detected ]
-------------------------------------------------------
cpuspeed/1480 is trying to acquire lock:
 (&policy->lock){--..}, at: [<ffffffff8026875a>] mutex_lock+0x2a/0x2e

but task is already holding lock:
 (cpucontrol){--..}, at: [<ffffffff8026875a>] mutex_lock+0x2a/0x2e

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (cpucontrol){--..}:
       [<ffffffff802abb1c>] lock_acquire+0x4a/0x69
       [<ffffffff8026857c>] __mutex_lock_slowpath+0xeb/0x29f
       [<ffffffff80268759>] mutex_lock+0x29/0x2e
       [<ffffffff802af048>] __lock_cpu_hotplug+0x3c/0x5f
       [<ffffffff802af085>] lock_cpu_hotplug+0xa/0xd
       [<ffffffff8041a7fd>] __cpufreq_driver_target+0x1a/0x81
       [<ffffffff8041babe>] cpufreq_governor_userspace+0x1e9/0x22c
       [<ffffffff8041a1b5>] __cpufreq_governor+0x74/0x107
       [<ffffffff8041a41d>] __cpufreq_set_policy+0x1d5/0x1e7
       [<ffffffff8041a46a>] cpufreq_set_policy+0x3b/0x97
       [<ffffffff8041b046>] cpufreq_add_dev+0x3ac/0x57b
       [<ffffffff803ba8fa>] sysdev_driver_register+0xa7/0x13a
       [<ffffffff8041a061>] cpufreq_register_driver+0xc1/0x1a1
       [<ffffffff8028044c>] powernowk8_init+0x7e/0x88
       [<ffffffff8026fde4>] init+0x1fc/0x3cd
       [<ffffffff8026315d>] child_rip+0x7/0x12

-> #1 (userspace_mutex){--..}:
       [<ffffffff802abb1c>] lock_acquire+0x4a/0x69
       [<ffffffff8026857c>] __mutex_lock_slowpath+0xeb/0x29f
       [<ffffffff80268759>] mutex_lock+0x29/0x2e
       [<ffffffff8041b93a>] cpufreq_governor_userspace+0x65/0x22c
       [<ffffffff8041a1b5>] __cpufreq_governor+0x74/0x107
       [<ffffffff8041a3bc>] __cpufreq_set_policy+0x174/0x1e7
       [<ffffffff8041a46a>] cpufreq_set_policy+0x3b/0x97
       [<ffffffff8041b046>] cpufreq_add_dev+0x3ac/0x57b
       [<ffffffff803ba8fa>] sysdev_driver_register+0xa7/0x13a
       [<ffffffff8041a061>] cpufreq_register_driver+0xc1/0x1a1
       [<ffffffff8028044c>] powernowk8_init+0x7e/0x88
       [<ffffffff8026fde4>] init+0x1fc/0x3cd
       [<ffffffff8026315d>] child_rip+0x7/0x12

-> #0 (&policy->lock){--..}:
       [<ffffffff802abb1c>] lock_acquire+0x4a/0x69
       [<ffffffff8026857c>] __mutex_lock_slowpath+0xeb/0x29f
       [<ffffffff80268759>] mutex_lock+0x29/0x2e
       [<ffffffff8041a614>] store_scaling_governor+0x14e/0x19c
       [<ffffffff80277bda>] store+0x4b/0x66
       [<ffffffff8030ff92>] sysfs_write_file+0xd0/0x103
       [<ffffffff8021785e>] vfs_write+0xce/0x175
       [<ffffffff8021814c>] sys_write+0x46/0x70
       [<ffffffff8026220d>] system_call+0x7d/0x83

other info that might help us debug this:

1 lock held by cpuspeed/1480:
 #0:  (cpucontrol){--..}, at: [<ffffffff8026875a>] mutex_lock+0x2a/0x2e

stack backtrace:

Call Trace:
 [<ffffffff80270de5>] show_trace+0xaa/0x23d
 [<ffffffff80270f8d>] dump_stack+0x15/0x17
 [<ffffffff802a9d76>] print_circular_bug_tail+0x6c/0x77
 [<ffffffff802ab37b>] __lock_acquire+0x853/0xa54
 [<ffffffff802abb1d>] lock_acquire+0x4b/0x69
 [<ffffffff8026857d>] __mutex_lock_slowpath+0xec/0x29f
 [<ffffffff8026875a>] mutex_lock+0x2a/0x2e
 [<ffffffff8041a615>] store_scaling_governor+0x14f/0x19c
 [<ffffffff80277bdb>] store+0x4c/0x66
 [<ffffffff8030ff93>] sysfs_write_file+0xd1/0x103
 [<ffffffff8021785f>] vfs_write+0xcf/0x175
 [<ffffffff8021814d>] sys_write+0x47/0x70
 [<ffffffff8026220e>] system_call+0x7e/0x83





More information about the fedora-test-list mailing list