On 03/26/2012 10:11 PM, Paul E. McKenney wrote:

On Tue, Mar 27, 2012 at 02:07:14AM +0200, Eric Dumazet wrote:

quoted

On Mon, 2012-03-26 at 16:46 -0700, Ben Greear wrote:

quoted

The 3.0.21 kernel doesn't appear to have a rcu_read_lock_return(),
so I can't use your patch below.

This patch was only to show the point (I also CCed Paul, he might have
some time to think about it, after he clears the inline stuff with
Linus)

There is an rcu_preempt_depth() that returns rcu_read_lock() nesting
level for CONFIG_PREEMPT_RCU=y on the one hand and returns zero
for CONFIG_PREEMPT_RCU=n on the other.  So if you can reproduce
with CONFIG_PREEMPT_RCU=y, you can substitute rcu_preempt_depth()
rcu_read_lock_return() in Eric's earlier patch.

I'll try looking at that tomorrow.  I tried adding some code to check for
recursive calls to the fib-dump, and didn't see it ever hit, though
the bug continued to happen readily.

I just #if 0 the part between rcu-read-lock and read-unlock, and
the problem went away..but of course you can't dump ipv6
routes then...

The actual logic to dump the fib is quite complex, full of
opaque types and other stuff ripe for bugs.  But, I don't see
how it could cause the rcu splats in such a repeatable manner.

The bug is always reported as being in the same place, so if
there is any other debugging code you can think of to help
shed light on this, I'll be happy to add it and give it a try.
For instance, is there a way to dump (print) all current holders of
the rcu_read_lock?  I could call that before/during/after in that
method and maybe get a clue.

Thanks,
Ben

							Thanx, Paul

quoted

As I said, I was referreing to you adding stuff in rcu. ;)

Unfortunately I wont have time in the near future to do so myself.

-- 
Ben Greear [off-list ref]
Candela Technologies Inc  http://www.candelatech.com