[lkml]   [2013]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Question on lockdep and MAX_LOCK_DEPTH
On Tue, 2013-02-05 at 18:26 -0800, Ben Greear wrote:
> Well, here it is..something is calling rcu_read_lock lots and lots,

Or a bug in the way lockdep handles rcu mappings.

> it seems. Any way to get a better idea of where those calls are
> made?

Yeah, with ftrace.

> 96 locks held by swapper/0/0:
> #0: (rcu_read_lock){.+.+..}, at: [<ffffffff81476836>] rcu_read_lock+0x0/0x6f
> #1: (rcu_read_lock){.+.+..}, at: [<ffffffff81476836>] rcu_read_lock+0x0/0x6f
> #92: (rcu_read_lock){.+.+..}, at: [<ffffffff81476836>] rcu_read_lock+0x0/0x6f
> #93: (&(&wl->cfg_spin_lock)->rlock){..-...}, at: [<ffffffffa07bc4d0>] handle_rcv+0x15d/0x1dd [wanlink]
> #94: (&wl_threads[q].my_wq){..-...}, at: [<ffffffff810abe4d>] __wake_up+0x1d/0x48
> #95: (&p->pi_lock){-.-.-.}, at: [<ffffffff810b09c1>] try_to_wake_up+0x29/0x20b

If you haven't already configured ftrace into your kernel, can you
please do so. Specifically:


Then, before triggering this, run the following as root:

# mount -t debugfs nodev /sys/kernel/debug
# cd /sys/kernel/debug/tracing
# echo net_rx_action > set_graph_function
# echo function_graph > current_tracer

In the kernel, where you added the above dump, before any of the printks
happen, add this too:


This will stop the trace at the point of the error. The trace_printk()
is a nice way to see the trace too.

Then after you trigger the bug, do the following:

cat /sys/kernel/debug/tracing/trace

and reply with that.

To turn tracing on again (because the tracing_off() disabled it), you
can do:

echo 1 > /sys/kernel/debug/tracing/tracing_on

Careful not to do "echo 1> ..." ;-)

-- Steve

 \ /
  Last update: 2013-02-06 04:41    [W:0.061 / U:8.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site