Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[BUG]: Possibe recursive locking detected in sysfs

1 view
Skip to first unread message

John Kacur

unread,
Feb 11, 2010, 12:20:01 PM2/11/10
to
I'm not sure if this one has already been reported. - thanks.

Feb 11 07:24:15 localhost kernel: [ INFO: possible recursive locking detected ]
Feb 11 07:24:15 localhost kernel: 2.6.33-rc7 #1
Feb 11 07:24:15 localhost kernel: ---------------------------------------------
Feb 11 07:24:15 localhost kernel: 94cpufreq/2933 is trying to acquire lock:
Feb 11 07:24:15 localhost kernel: (s_active){++++.+}, at:
[<ffffffff81157408>] sysfs_hash_and_remove+0x53/0x6a
Feb 11 07:24:15 localhost kernel:
Feb 11 07:24:15 localhost kernel: but task is already holding lock:
Feb 11 07:24:15 localhost kernel: (s_active){++++.+}, at:
[<ffffffff81159530>] sysfs_get_active_two+0x24/0x48
Feb 11 07:24:15 localhost kernel:
Feb 11 07:24:15 localhost kernel: other info that might help us debug this:
Feb 11 07:24:15 localhost kernel: 4 locks held by 94cpufreq/2933:
Feb 11 07:24:15 localhost kernel: #0: (&buffer->mutex){+.+.+.}, at:
[<ffffffff81157dbd>] sysfs_write_file+0x3e/0x12b
Feb 11 07:24:15 localhost kernel: #1: (s_active){++++.+}, at:
[<ffffffff81159530>] sysfs_get_active_two+0x24/0x48
Feb 11 07:24:15 localhost kernel: #2: (s_active){++++.+}, at:
[<ffffffff8115953d>] sysfs_get_active_two+0x31/0x48
Feb 11 07:24:15 localhost kernel: #3: (dbs_mutex){+.+.+.}, at:
[<ffffffffa04bcdb3>] cpufreq_governor_dbs+0x29b/0x348
[cpufreq_ondemand]
Feb 11 07:24:15 localhost kernel:
Feb 11 07:24:15 localhost kernel: stack backtrace:
Feb 11 07:24:15 localhost kernel: Pid: 2933, comm: 94cpufreq Not
tainted 2.6.33-rc7 #1
Feb 11 07:24:15 localhost kernel: Call Trace:
Feb 11 07:24:15 localhost kernel: [<ffffffff81071f53>]
__lock_acquire+0xcf6/0xd8b
Feb 11 07:24:15 localhost kernel: [<ffffffff81070914>] ?
debug_check_no_locks_freed+0x120/0x12f
Feb 11 07:24:15 localhost kernel: [<ffffffff8107020e>] ?
trace_hardirqs_on_caller+0x11f/0x14a
Feb 11 07:24:15 localhost kernel: [<ffffffff810720c0>] lock_acquire+0xd8/0xf5
Feb 11 07:24:15 localhost kernel: [<ffffffff81157408>] ?
sysfs_hash_and_remove+0x53/0x6a
Feb 11 07:24:15 localhost kernel: [<ffffffff81159231>]
sysfs_addrm_finish+0xe1/0x175
Feb 11 07:24:15 localhost kernel: [<ffffffff81157408>] ?
sysfs_hash_and_remove+0x53/0x6a
Feb 11 07:24:15 localhost kernel: [<ffffffff8137b1b5>] ?
sub_preempt_count+0xa3/0xb6
Feb 11 07:24:15 localhost kernel: [<ffffffff81157408>]
sysfs_hash_and_remove+0x53/0x6a
Feb 11 07:24:15 localhost kernel: [<ffffffff8115a59d>]
sysfs_remove_group+0x91/0xc9
Feb 11 07:24:15 localhost kernel: [<ffffffffa04bcdc6>]
cpufreq_governor_dbs+0x2ae/0x348 [cpufreq_ondemand]
Feb 11 07:24:15 localhost kernel: [<ffffffff8137b1b5>] ?
sub_preempt_count+0xa3/0xb6
Feb 11 07:24:15 localhost kernel: [<ffffffff812ab9cc>]
__cpufreq_governor+0x89/0xc7
Feb 11 07:24:15 localhost kernel: [<ffffffff812ac7b9>]
__cpufreq_set_policy+0x18e/0x22a
Feb 11 07:24:15 localhost kernel: [<ffffffff812accd6>]
store_scaling_governor+0x199/0x1ed
Feb 11 07:24:15 localhost kernel: [<ffffffff812ad50d>] ? handle_update+0x0/0x39
Feb 11 07:24:15 localhost kernel: [<ffffffff8137685d>] ? down_write+0x76/0x7e
Feb 11 07:24:15 localhost kernel: [<ffffffff812ac607>] store+0x67/0x8b
Feb 11 07:24:15 localhost kernel: [<ffffffff81157e75>]
sysfs_write_file+0xf6/0x12b
Feb 11 07:24:15 localhost kernel: [<ffffffff811003c9>] vfs_write+0xb0/0x10a
Feb 11 07:24:15 localhost kernel: [<ffffffff811004f1>] sys_write+0x4c/0x75
Feb 11 07:24:15 localhost kernel: [<ffffffff81002d9b>]
system_call_fastpath+0x16/0x1b
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

John Kacur

unread,
Feb 14, 2010, 8:20:02 AM2/14/10
to

This is still present in 2.6.33-rc8.
I can trigger it every time. I have T500 laptop, the trick is to boot
it up without plugging it in, so it is working on battery power, and
then to shut the lid.
first you get the message from above, and then it does a few more
things before it freezes and I have to hard reboot it.
The above problem does not occur if I have the laptop plugged into the wall.

Here is the 2.6.33-rc8 version of above. If anyone has further
suggestions for debugging, pls let me know.
I've cced the folks that get_maintainer.pl reports for
fs/sysfs/inode.c and fs/sysfs/dir.c

Feb 14 07:35:49 localhost kernel: =============================================
Feb 14 07:35:49 localhost kernel: [ INFO: possible recursive locking detected ]
Feb 14 07:35:49 localhost kernel: 2.6.33-rc8 #1
Feb 14 07:35:49 localhost kernel: ---------------------------------------------
Feb 14 07:35:49 localhost kernel: 94cpufreq/2914 is trying to acquire lock:
Feb 14 07:35:49 localhost kernel: (s_active){++++.+}, at:
[<ffffffff81157478>] sysfs_hash_and_remove+0x53/0x6a
Feb 14 07:35:49 localhost kernel:
Feb 14 07:35:49 localhost kernel: but task is already holding lock:
Feb 14 07:35:49 localhost kernel: (s_active){++++.+}, at:
[<ffffffff811595a0>] sysfs_get_active_two+0x24/0x48
Feb 14 07:35:49 localhost kernel:
Feb 14 07:35:49 localhost kernel: other info that might help us debug this:
Feb 14 07:35:49 localhost kernel: 4 locks held by 94cpufreq/2914:
Feb 14 07:35:49 localhost kernel: #0: (&buffer->mutex){+.+.+.}, at:
[<ffffffff81157e2d>] sysfs_write_file+0x3e/0x12b
Feb 14 07:35:49 localhost kernel: #1: (s_active){++++.+}, at:
[<ffffffff811595a0>] sysfs_get_active_two+0x24/0x48
Feb 14 07:35:49 localhost kernel: #2: (s_active){++++.+}, at:
[<ffffffff811595ad>] sysfs_get_active_two+0x31/0x48
Feb 14 07:35:49 localhost kernel: #3: (dbs_mutex){+.+.+.}, at:
[<ffffffffa04c0dbe>] cpufreq_governor_dbs+0x29b/0x345
[cpufreq_ondemand]
Feb 14 07:35:49 localhost kernel:
Feb 14 07:35:49 localhost kernel: stack backtrace:
Feb 14 07:35:49 localhost kernel: Pid: 2914, comm: 94cpufreq Not
tainted 2.6.33-rc8 #1
Feb 14 07:35:49 localhost kernel: Call Trace:
Feb 14 07:35:49 localhost kernel: [<ffffffff81071f53>]
__lock_acquire+0xcf6/0xd8b
Feb 14 07:35:49 localhost kernel: [<ffffffff81070914>] ?
debug_check_no_locks_freed+0x120/0x12f
Feb 14 07:35:49 localhost kernel: [<ffffffff8107020e>] ?
trace_hardirqs_on_caller+0x11f/0x14a
Feb 14 07:35:49 localhost kernel: [<ffffffff810720c0>] lock_acquire+0xd8/0xf5
Feb 14 07:35:49 localhost kernel: [<ffffffff81157478>] ?
sysfs_hash_and_remove+0x53/0x6a
Feb 14 07:35:49 localhost kernel: [<ffffffff811592a1>]
sysfs_addrm_finish+0xe1/0x175
Feb 14 07:35:49 localhost kernel: [<ffffffff81157478>] ?
sysfs_hash_and_remove+0x53/0x6a
Feb 14 07:35:49 localhost kernel: [<ffffffff8137b335>] ?
sub_preempt_count+0xa3/0xb6
Feb 14 07:35:49 localhost kernel: [<ffffffff81157478>]
sysfs_hash_and_remove+0x53/0x6a
Feb 14 07:35:49 localhost kernel: [<ffffffff8115a60d>]
sysfs_remove_group+0x91/0xc9
Feb 14 07:35:49 localhost kernel: [<ffffffffa04c0dd1>]
cpufreq_governor_dbs+0x2ae/0x345 [cpufreq_ondemand]
Feb 14 07:35:49 localhost kernel: [<ffffffff8137b335>] ?
sub_preempt_count+0xa3/0xb6
Feb 14 07:35:49 localhost kernel: [<ffffffff812aba60>]
__cpufreq_governor+0x89/0xc7
Feb 14 07:35:49 localhost kernel: [<ffffffff812ac84d>]
__cpufreq_set_policy+0x18e/0x22a
Feb 14 07:35:49 localhost kernel: [<ffffffff812acd6a>]
store_scaling_governor+0x199/0x1ed
Feb 14 07:35:49 localhost kernel: [<ffffffff812ad5a1>] ? handle_update+0x0/0x39
Feb 14 07:35:49 localhost kernel: [<ffffffff813769ad>] ? down_write+0x76/0x7e
Feb 14 07:35:49 localhost kernel: [<ffffffff812ac69b>] store+0x67/0x8b
Feb 14 07:35:49 localhost kernel: [<ffffffff81157ee5>]
sysfs_write_file+0xf6/0x12b
Feb 14 07:35:49 localhost kernel: [<ffffffff811003c9>] vfs_write+0xb0/0x10a
Feb 14 07:35:49 localhost kernel: [<ffffffff811004f1>] sys_write+0x4c/0x75
Feb 14 07:35:49 localhost kernel: [<ffffffff81002d9b>]

Eric Biederman

unread,
Feb 14, 2010, 10:00:01 AM2/14/10
to

We have a real hang and a possibly spurious lockdep report.
Could you try my latest patches that I sent to gregkh to clear up the sysfs
lockdep reports? I don't expect it will fix your issue but it will
at least give
us a better idea of where to look.

Eric

John Kacur

unread,
Feb 14, 2010, 4:00:01 PM2/14/10
to
Sure, are you referring to the patch-set that begins with
"[PATCH 1/6] sysfs: Serialize updates to the vfs inode"?

Eric Biederman

unread,
Feb 14, 2010, 5:00:03 PM2/14/10
to
> Sure, are you referring to the patch-set that begins with
> "[PATCH 1/6] sysfs: Serialize updates to the vfs inode"?

Sorry no.

http://lkml.org/lkml/2010/2/11/329

Eric

John Kacur

unread,
Feb 14, 2010, 9:30:01 PM2/14/10
to
On Sun, Feb 14, 2010 at 4:50 PM, Eric Biederman
<ebie...@aristanetworks.com> wrote:
>> Sure, are you referring to the patch-set that begins with
>> "[PATCH 1/6] sysfs: Serialize updates to the vfs inode"?
>
> Sorry no.
>
> http://lkml.org/lkml/2010/2/11/329
>

I applied your patch, and yes, it removed the possible recursive
locking detected message, but everything still froze.
I don't think I really have any good info from the crash to report.
Your patch seems to have added the symptom of a huge number of
BUG: key ffff880126269e40 not in .data!
BUG: key ffff880136fc03f0 not in .data!

messages to my log.

If there is any other info that I can provide that would be useful,
please let me know.

Eric Biederman

unread,
Feb 15, 2010, 5:10:02 AM2/15/10
to
On Sun, Feb 14, 2010 at 6:22 PM, John Kacur <jka...@redhat.com> wrote:
> On Sun, Feb 14, 2010 at 4:50 PM, Eric Biederman
> <ebie...@aristanetworks.com> wrote:
>>> Sure, are you referring to the patch-set that begins with
>>> "[PATCH 1/6] sysfs: Serialize updates to the vfs inode"?
>>
>> Sorry no.
>>
>> http://lkml.org/lkml/2010/2/11/329
>>
>
> I applied your patch, and yes, it removed the possible recursive
> locking detected message, but everything still froze.
> I don't think I really have any good info from the crash to report.
> Your patch seems to have added the symptom of a huge number of
> BUG: key ffff880126269e40 not in .data!
> BUG: key ffff880136fc03f0 not in .data!

Those are from dynamic sysfs entries that I have not yet annoted
with sysfs_attr_init, and are generally harmless. If you happen
to see the first one. I would appreciate having the backtrace so I
can see about fixing it.

With respect to your problem the important point is that lockdep does
not throw a warning and disable itself. Can you verify that?

Assuming that lockdep has not complained and disabled itself than
my patches are successful at disabling the sysfs lockdep false positives
(except those BUG: key ... not in .data messages). and the lockdep
warnings are just a coincidence in your case.

I believe the cause of your hang is somewhere else entirely. Perhaps
a driver regression.

Eric

Américo Wang

unread,
Feb 15, 2010, 5:40:02 AM2/15/10
to

Right, we got a real deadlock here:

http://lkml.org/lkml/2010/1/28/320

Maciej Rutecki

unread,
Feb 15, 2010, 2:50:01 PM2/15/10
to
On czwartek, 11 lutego 2010 o 18:11:46 John Kacur wrote:
> I'm not sure if this one has already been reported. - thanks.
>
> Feb 11 07:24:15 localhost kernel: [ INFO: possible recursive locking
> detected ] Feb 11 07:24:15 localhost kernel: 2.6.33-rc7 #1
[...]

I created a Bugzilla entry at http://bugzilla.kernel.org/show_bug.cgi?id=15319
for your bug report, please add your address to the CC list in there, thanks!


--
Maciej Rutecki
http://www.maciek.unixy.pl

0 new messages