Thread (3 messages) 3 messages, 2 authors, 2012-06-27

Re: "Regression" with cd3d09527537

From: Glauber Costa <hidden>
Date: 2012-06-27 23:10:19
Also in: lkml

On 06/28/2012 03:08 AM, Tejun Heo wrote:
On Tue, Jun 26, 2012 at 04:43:03PM +0400, Glauber Costa wrote:
quoted
Hi,

I've recently started seeing a lockdep warning at the end of *every*
"init 0" issued in my machine. Actually, reboots are fine, and
that's probably why I've never seen it earlier. The log is quite
extensively, but shows the following dependency chain:

[   83.982111] -> #4 (cpu_hotplug.lock){+.+.+.}:
[...]
[   83.982111] -> #3 (jump_label_mutex){+.+...}:
[...]
[   83.982111] -> #2 (sk_lock-AF_INET){+.+.+.}:
[...]
[   83.982111] -> #1 (&sig->cred_guard_mutex){+.+.+.}:
[...]
[   83.982111] -> #0 (cgroup_mutex){+.+.+.}:

I've recently fixed bugs with the lock ordering imposed by cpusets
on cpu_hotplug.lock through jump_label_mutex, and initially thought
it to be the same kind of issue. But that was not the case.

I've omitted the full backtrace for readability, but I run this with
all cgroups disabled but the cpuset, so it can't be sock memcg
(after my initial reaction of "oh, fuck, not again"). That
jump_label is there for years, and it comes from the code that
disables socket timestamps.
(net_enable_timestamp)
Yeah, there are multiple really large locks at play here - jump label,
threadgroup and cgroup_mutex.  It isn't pretty.  Can you please post
the full lockdep dump?  The above only shows single locking chain.
I'd like to see the other.

Thanks.
  

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help