Fw: rcu warning

Fw: rcu warning

[Paul E. McKenney]

> Date: Wed, 22 Sep 2010 13:52:28 -0700
> From: Andrew Morton <akpm@linux-foundation.org>
> To: "Paul E. McKenney" <paulmck@us.ibm.com>
> Subject: rcu warning
> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; x86_64-pc-linux-gnu)
> 
> [   56.803750] 
> [   56.803752] ===================================================
> [   56.804082] [ INFO: suspicious rcu_dereference_check() usage. ]
> [   56.804249] ---------------------------------------------------
> [   56.804421] include/linux/inetdevice.h:219 invoked rcu_dereference_check() without protection!
> [   56.804708] 
> [   56.804709] other info that might help us debug this:
> [   56.804710] 
> [   56.805183] 
> [   56.805184] rcu_scheduler_active = 1, debug_locks = 1
> [   56.805501] 3 locks held by kworker/0:1/0:
> [   56.805664]  #0:  (&in_dev->mr_ifc_timer){+.-...}, at: [<ffffffff81042466>] run_timer_softirq+0xfd/0x226
> [   56.806126]  #1:  (&in_dev->mc_list_lock){++.-..}, at: [<ffffffff8133e81d>] igmp_ifc_timer_expire+0x2a/0x221
> [   56.806588]  #2:  (&(&im->lock)->rlock){+.-...}, at: [<ffffffff8133e948>] igmp_ifc_timer_expire+0x155/0x221
> [   56.807043] 
> [   56.807044] stack backtrace:
> [   56.807364] Pid: 0, comm: kworker/0:1 Not tainted 2.6.36-rc5-mm1 #1
> [   56.807561] Call Trace:
> [   56.807723]  <IRQ>  [<ffffffff8105b88b>] lockdep_rcu_dereference+0x99/0xa2
> [   56.807948]  [<ffffffff8130dc66>] __ip_route_output_key+0x34f/0xb19
> [   56.808120]  [<ffffffff8130d94a>] ? __ip_route_output_key+0x33/0xb19
> [   56.814367]  [<ffffffff8130e453>] ip_route_output_flow+0x23/0x1ee
> [   56.814536]  [<ffffffff8130e62c>] ip_route_output_key+0xe/0x10
> [   56.814704]  [<ffffffff8133e19d>] igmpv3_newpack+0x7f/0x1c2
> [   56.814873]  [<ffffffff8133e30d>] add_grhead+0x2d/0x94
> [   56.815039]  [<ffffffff8133e6c2>] add_grec+0x34e/0x38c
> [   56.815206]  [<ffffffff8133e9a8>] igmp_ifc_timer_expire+0x1b5/0x221
> [   56.815375]  [<ffffffff810424e8>] run_timer_softirq+0x17f/0x226
> [   56.815547]  [<ffffffff81042466>] ? run_timer_softirq+0xfd/0x226
> [   56.815715]  [<ffffffff8133e7f3>] ? igmp_ifc_timer_expire+0x0/0x221
> [   56.815885]  [<ffffffff8103ca8f>] __do_softirq+0xa5/0x13a
> [   56.816051]  [<ffffffff8100390c>] call_softirq+0x1c/0x28
> [   56.816219]  [<ffffffff81004eba>] do_softirq+0x38/0x82
> [   56.816385]  [<ffffffff8103c9e8>] irq_exit+0x47/0x49
> [   56.816553]  [<ffffffff81019ce3>] smp_apic_timer_interrupt+0x88/0x96
> [   56.816722]  [<ffffffff810033d3>] apic_timer_interrupt+0x13/0x20
> [   56.816888]  <EOI>  [<ffffffff8138607a>] ? __atomic_notifier_call_chain+0x0/0x84
> [   56.817215]  [<ffffffff81009a9b>] ? mwait_idle+0x65/0x71
> [   56.817382]  [<ffffffff81009a91>] ? mwait_idle+0x5b/0x71
> [   56.817549]  [<ffffffff810014ca>] cpu_idle+0x48/0x66
> [   56.817716]  [<ffffffff8137b4da>] start_secondary+0x1b9/0x1bd
> [   56.817883]  [<ffffffff8137b321>] ? start_secondary+0x0/0x1bd

Hello, Eric,

In linux/master, there is an rcu_read_lock_bh() in the call path, but
an rcu_dereference() instead of an rcu_dereference_bh().  Thoughts?

(I have asked Andrew what kernel this is against -- I don't see the
rcu_read_lock() that I would expect to see in the lockdep output.)

							Thanx, Paul

> We seem to be getting way too many of these.
> 
> ----- End forwarded message -----

Re: Fw: rcu warning

[Andrew Morton]

On Wed, 22 Sep 2010 14:44:38 -0700
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:

> In linux/master, there is an rcu_read_lock_bh() in the call path, but
> an rcu_dereference() instead of an rcu_dereference_bh().  Thoughts?
> 
> (I have asked Andrew what kernel this is against -- I don't see the
> rcu_read_lock() that I would expect to see in the lockdep output.)

current linux-next.

Re: Fw: rcu warning

[Eric Dumazet]

Le mercredi 22 septembre 2010 à 14:44 -0700, Paul E. McKenney a écrit :
> > Date: Wed, 22 Sep 2010 13:52:28 -0700
> > From: Andrew Morton <akpm@linux-foundation.org>
> > To: "Paul E. McKenney" <paulmck@us.ibm.com>
> > Subject: rcu warning
> > X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; x86_64-pc-linux-gnu)
> > 
> > [   56.803750] 
> > [   56.803752] ===================================================
> > [   56.804082] [ INFO: suspicious rcu_dereference_check() usage. ]
> > [   56.804249] ---------------------------------------------------
> > [   56.804421] include/linux/inetdevice.h:219 invoked rcu_dereference_check() without protection!
> > [   56.804708] 
> > [   56.804709] other info that might help us debug this:
> > [   56.804710] 
> > [   56.805183] 
> > [   56.805184] rcu_scheduler_active = 1, debug_locks = 1
> > [   56.805501] 3 locks held by kworker/0:1/0:
> > [   56.805664]  #0:  (&in_dev->mr_ifc_timer){+.-...}, at: [<ffffffff81042466>] run_timer_softirq+0xfd/0x226
> > [   56.806126]  #1:  (&in_dev->mc_list_lock){++.-..}, at: [<ffffffff8133e81d>] igmp_ifc_timer_expire+0x2a/0x221
> > [   56.806588]  #2:  (&(&im->lock)->rlock){+.-...}, at: [<ffffffff8133e948>] igmp_ifc_timer_expire+0x155/0x221
> > [   56.807043] 
> > [   56.807044] stack backtrace:
> > [   56.807364] Pid: 0, comm: kworker/0:1 Not tainted 2.6.36-rc5-mm1 #1
> > [   56.807561] Call Trace:
> > [   56.807723]  <IRQ>  [<ffffffff8105b88b>] lockdep_rcu_dereference+0x99/0xa2
> > [   56.807948]  [<ffffffff8130dc66>] __ip_route_output_key+0x34f/0xb19
> > [   56.808120]  [<ffffffff8130d94a>] ? __ip_route_output_key+0x33/0xb19
> > [   56.814367]  [<ffffffff8130e453>] ip_route_output_flow+0x23/0x1ee
> > [   56.814536]  [<ffffffff8130e62c>] ip_route_output_key+0xe/0x10
> > [   56.814704]  [<ffffffff8133e19d>] igmpv3_newpack+0x7f/0x1c2
> > [   56.814873]  [<ffffffff8133e30d>] add_grhead+0x2d/0x94
> > [   56.815039]  [<ffffffff8133e6c2>] add_grec+0x34e/0x38c
> > [   56.815206]  [<ffffffff8133e9a8>] igmp_ifc_timer_expire+0x1b5/0x221
> > [   56.815375]  [<ffffffff810424e8>] run_timer_softirq+0x17f/0x226
> > [   56.815547]  [<ffffffff81042466>] ? run_timer_softirq+0xfd/0x226
> > [   56.815715]  [<ffffffff8133e7f3>] ? igmp_ifc_timer_expire+0x0/0x221
> > [   56.815885]  [<ffffffff8103ca8f>] __do_softirq+0xa5/0x13a
> > [   56.816051]  [<ffffffff8100390c>] call_softirq+0x1c/0x28
> > [   56.816219]  [<ffffffff81004eba>] do_softirq+0x38/0x82
> > [   56.816385]  [<ffffffff8103c9e8>] irq_exit+0x47/0x49
> > [   56.816553]  [<ffffffff81019ce3>] smp_apic_timer_interrupt+0x88/0x96
> > [   56.816722]  [<ffffffff810033d3>] apic_timer_interrupt+0x13/0x20
> > [   56.816888]  <EOI>  [<ffffffff8138607a>] ? __atomic_notifier_call_chain+0x0/0x84
> > [   56.817215]  [<ffffffff81009a9b>] ? mwait_idle+0x65/0x71
> > [   56.817382]  [<ffffffff81009a91>] ? mwait_idle+0x5b/0x71
> > [   56.817549]  [<ffffffff810014ca>] cpu_idle+0x48/0x66
> > [   56.817716]  [<ffffffff8137b4da>] start_secondary+0x1b9/0x1bd
> > [   56.817883]  [<ffffffff8137b321>] ? start_secondary+0x0/0x1bd
> 
> Hello, Eric,
> 
> In linux/master, there is an rcu_read_lock_bh() in the call path, but
> an rcu_dereference() instead of an rcu_dereference_bh().  Thoughts?
> 
> (I have asked Andrew what kernel this is against -- I don't see the
> rcu_read_lock() that I would expect to see in the lockdep output.)
> 
> 							Thanx, Paul

This seems strange

include/linux/inetdevice.h:219

static inline struct in_device *__in_dev_get_rtnl(const struct net_device *dev)
{
	return rcu_dereference_check(dev->ip_ptr, lockdep_rtnl_is_held());
}

But I dont think RTNL can possibly be held at this point ???

Oh wait, this is line 2582 in net/ipv4/route.c

It seems buggy and proud of it :)

	/* RACE: Check return value of inet_select_addr instead. */ 
	if (__in_dev_get_rtnl(dev_out) == NULL) {

This should be changed to 

	if (rcu_dereference_raw(dev_out->ip_ptr) == NULL) {

No ?


In commit e5ed639913eea3e, Herbert mentioned a race so I suspect some
more thinking is needed before applying the following patch

Sorry its late here, I now need to sleep :)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index e24d48d..8d08377 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2579,7 +2579,7 @@ static int ip_route_output_slow(struct net *net, struct rtable **rp,
 			goto out;
 
 		/* RACE: Check return value of inet_select_addr instead. */
-		if (__in_dev_get_rtnl(dev_out) == NULL) {
+		if (rcu_dereference_raw(dev_out->ip_ptr) == NULL) {
 			dev_put(dev_out);
 			goto out;	/* Wrong error code */
 		}

Re: Fw: rcu warning

[Paul E. McKenney]

On Wed, Sep 22, 2010 at 02:47:36PM -0700, Andrew Morton wrote:
> On Wed, 22 Sep 2010 14:44:38 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> 
> > In linux/master, there is an rcu_read_lock_bh() in the call path, but
> > an rcu_dereference() instead of an rcu_dereference_bh().  Thoughts?
> > 
> > (I have asked Andrew what kernel this is against -- I don't see the
> > rcu_read_lock() that I would expect to see in the lockdep output.)
> 
> current linux-next.

Thank you!!!

OK, here we have __in_dev_get_rtnl() called from ip_route_output_slow().
I might be missing something, but I don't see either an rcu_read_lock()
or an RTNL acquisition in ip_route_output_slow().

But the call to __in_dev_get_rtnl() simply compares to NULL, so I don't
understand why this can't instead call __in_dev_get_rcu().  Given that
there are a number of places where the return value from __in_dev_get_rtnl()
is compared to NULL, one approach would be to have something like the
following:

	static inline int __in_dev_check_null(const struct net_device *dev)
	{
		return rcu_dereference_raw(dev->ip_ptr) == NULL;
	}

Thoughts?

							Thanx, Paul

Re: Fw: rcu warning

[Paul E. McKenney]

On Thu, Sep 23, 2010 at 01:04:25AM +0200, Eric Dumazet wrote:
> Le mercredi 22 septembre 2010 à 14:44 -0700, Paul E. McKenney a écrit :
> > > Date: Wed, 22 Sep 2010 13:52:28 -0700
> > > From: Andrew Morton <akpm@linux-foundation.org>
> > > To: "Paul E. McKenney" <paulmck@us.ibm.com>
> > > Subject: rcu warning
> > > X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; x86_64-pc-linux-gnu)
> > > 
> > > [   56.803750] 
> > > [   56.803752] ===================================================
> > > [   56.804082] [ INFO: suspicious rcu_dereference_check() usage. ]
> > > [   56.804249] ---------------------------------------------------
> > > [   56.804421] include/linux/inetdevice.h:219 invoked rcu_dereference_check() without protection!
> > > [   56.804708] 
> > > [   56.804709] other info that might help us debug this:
> > > [   56.804710] 
> > > [   56.805183] 
> > > [   56.805184] rcu_scheduler_active = 1, debug_locks = 1
> > > [   56.805501] 3 locks held by kworker/0:1/0:
> > > [   56.805664]  #0:  (&in_dev->mr_ifc_timer){+.-...}, at: [<ffffffff81042466>] run_timer_softirq+0xfd/0x226
> > > [   56.806126]  #1:  (&in_dev->mc_list_lock){++.-..}, at: [<ffffffff8133e81d>] igmp_ifc_timer_expire+0x2a/0x221
> > > [   56.806588]  #2:  (&(&im->lock)->rlock){+.-...}, at: [<ffffffff8133e948>] igmp_ifc_timer_expire+0x155/0x221
> > > [   56.807043] 
> > > [   56.807044] stack backtrace:
> > > [   56.807364] Pid: 0, comm: kworker/0:1 Not tainted 2.6.36-rc5-mm1 #1
> > > [   56.807561] Call Trace:
> > > [   56.807723]  <IRQ>  [<ffffffff8105b88b>] lockdep_rcu_dereference+0x99/0xa2
> > > [   56.807948]  [<ffffffff8130dc66>] __ip_route_output_key+0x34f/0xb19
> > > [   56.808120]  [<ffffffff8130d94a>] ? __ip_route_output_key+0x33/0xb19
> > > [   56.814367]  [<ffffffff8130e453>] ip_route_output_flow+0x23/0x1ee
> > > [   56.814536]  [<ffffffff8130e62c>] ip_route_output_key+0xe/0x10
> > > [   56.814704]  [<ffffffff8133e19d>] igmpv3_newpack+0x7f/0x1c2
> > > [   56.814873]  [<ffffffff8133e30d>] add_grhead+0x2d/0x94
> > > [   56.815039]  [<ffffffff8133e6c2>] add_grec+0x34e/0x38c
> > > [   56.815206]  [<ffffffff8133e9a8>] igmp_ifc_timer_expire+0x1b5/0x221
> > > [   56.815375]  [<ffffffff810424e8>] run_timer_softirq+0x17f/0x226
> > > [   56.815547]  [<ffffffff81042466>] ? run_timer_softirq+0xfd/0x226
> > > [   56.815715]  [<ffffffff8133e7f3>] ? igmp_ifc_timer_expire+0x0/0x221
> > > [   56.815885]  [<ffffffff8103ca8f>] __do_softirq+0xa5/0x13a
> > > [   56.816051]  [<ffffffff8100390c>] call_softirq+0x1c/0x28
> > > [   56.816219]  [<ffffffff81004eba>] do_softirq+0x38/0x82
> > > [   56.816385]  [<ffffffff8103c9e8>] irq_exit+0x47/0x49
> > > [   56.816553]  [<ffffffff81019ce3>] smp_apic_timer_interrupt+0x88/0x96
> > > [   56.816722]  [<ffffffff810033d3>] apic_timer_interrupt+0x13/0x20
> > > [   56.816888]  <EOI>  [<ffffffff8138607a>] ? __atomic_notifier_call_chain+0x0/0x84
> > > [   56.817215]  [<ffffffff81009a9b>] ? mwait_idle+0x65/0x71
> > > [   56.817382]  [<ffffffff81009a91>] ? mwait_idle+0x5b/0x71
> > > [   56.817549]  [<ffffffff810014ca>] cpu_idle+0x48/0x66
> > > [   56.817716]  [<ffffffff8137b4da>] start_secondary+0x1b9/0x1bd
> > > [   56.817883]  [<ffffffff8137b321>] ? start_secondary+0x0/0x1bd
> > 
> > Hello, Eric,
> > 
> > In linux/master, there is an rcu_read_lock_bh() in the call path, but
> > an rcu_dereference() instead of an rcu_dereference_bh().  Thoughts?
> > 
> > (I have asked Andrew what kernel this is against -- I don't see the
> > rcu_read_lock() that I would expect to see in the lockdep output.)
> > 
> > 							Thanx, Paul
> 
> This seems strange
> 
> include/linux/inetdevice.h:219
> 
> static inline struct in_device *__in_dev_get_rtnl(const struct net_device *dev)
> {
> 	return rcu_dereference_check(dev->ip_ptr, lockdep_rtnl_is_held());
> }
> 
> But I dont think RTNL can possibly be held at this point ???
> 
> Oh wait, this is line 2582 in net/ipv4/route.c
> 
> It seems buggy and proud of it :)
> 
> 	/* RACE: Check return value of inet_select_addr instead. */ 
> 	if (__in_dev_get_rtnl(dev_out) == NULL) {
> 
> This should be changed to 
> 
> 	if (rcu_dereference_raw(dev_out->ip_ptr) == NULL) {
> 
> No ?

You beat me to it.  ;-)

							Thanx, Paul

> In commit e5ed639913eea3e, Herbert mentioned a race so I suspect some
> more thinking is needed before applying the following patch
> 
> Sorry its late here, I now need to sleep :)
> 
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index e24d48d..8d08377 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -2579,7 +2579,7 @@ static int ip_route_output_slow(struct net *net, struct rtable **rp,
>  			goto out;
> 
>  		/* RACE: Check return value of inet_select_addr instead. */
> -		if (__in_dev_get_rtnl(dev_out) == NULL) {
> +		if (rcu_dereference_raw(dev_out->ip_ptr) == NULL) {
>  			dev_put(dev_out);
>  			goto out;	/* Wrong error code */
>  		}
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next-2.6] net: fix rcu use in ip_route_output_slow

[Eric Dumazet]

Le mercredi 22 septembre 2010 à 16:12 -0700, Paul E. McKenney a écrit :
> On Thu, Sep 23, 2010 at 01:04:25AM +0200, Eric Dumazet wrote:
> > Le mercredi 22 septembre 2010 à 14:44 -0700, Paul E. McKenney a écrit :
> > > > Date: Wed, 22 Sep 2010 13:52:28 -0700
> > > > From: Andrew Morton <akpm@linux-foundation.org>
> > > > To: "Paul E. McKenney" <paulmck@us.ibm.com>
> > > > Subject: rcu warning
> > > > X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; x86_64-pc-linux-gnu)
> > > > 
> > > > [   56.803750] 
> > > > [   56.803752] ===================================================
> > > > [   56.804082] [ INFO: suspicious rcu_dereference_check() usage. ]
> > > > [   56.804249] ---------------------------------------------------
> > > > [   56.804421] include/linux/inetdevice.h:219 invoked rcu_dereference_check() without protection!
> > > > [   56.804708] 
> > > > [   56.804709] other info that might help us debug this:
> > > > [   56.804710] 
> > > > [   56.805183] 
> > > > [   56.805184] rcu_scheduler_active = 1, debug_locks = 1
> > > > [   56.805501] 3 locks held by kworker/0:1/0:
> > > > [   56.805664]  #0:  (&in_dev->mr_ifc_timer){+.-...}, at: [<ffffffff81042466>] run_timer_softirq+0xfd/0x226
> > > > [   56.806126]  #1:  (&in_dev->mc_list_lock){++.-..}, at: [<ffffffff8133e81d>] igmp_ifc_timer_expire+0x2a/0x221
> > > > [   56.806588]  #2:  (&(&im->lock)->rlock){+.-...}, at: [<ffffffff8133e948>] igmp_ifc_timer_expire+0x155/0x221
> > > > [   56.807043] 
> > > > [   56.807044] stack backtrace:
> > > > [   56.807364] Pid: 0, comm: kworker/0:1 Not tainted 2.6.36-rc5-mm1 #1
> > > > [   56.807561] Call Trace:
> > > > [   56.807723]  <IRQ>  [<ffffffff8105b88b>] lockdep_rcu_dereference+0x99/0xa2
> > > > [   56.807948]  [<ffffffff8130dc66>] __ip_route_output_key+0x34f/0xb19
> > > > [   56.808120]  [<ffffffff8130d94a>] ? __ip_route_output_key+0x33/0xb19
> > > > [   56.814367]  [<ffffffff8130e453>] ip_route_output_flow+0x23/0x1ee
> > > > [   56.814536]  [<ffffffff8130e62c>] ip_route_output_key+0xe/0x10
> > > > [   56.814704]  [<ffffffff8133e19d>] igmpv3_newpack+0x7f/0x1c2
> > > > [   56.814873]  [<ffffffff8133e30d>] add_grhead+0x2d/0x94
> > > > [   56.815039]  [<ffffffff8133e6c2>] add_grec+0x34e/0x38c
> > > > [   56.815206]  [<ffffffff8133e9a8>] igmp_ifc_timer_expire+0x1b5/0x221
> > > > [   56.815375]  [<ffffffff810424e8>] run_timer_softirq+0x17f/0x226
> > > > [   56.815547]  [<ffffffff81042466>] ? run_timer_softirq+0xfd/0x226
> > > > [   56.815715]  [<ffffffff8133e7f3>] ? igmp_ifc_timer_expire+0x0/0x221
> > > > [   56.815885]  [<ffffffff8103ca8f>] __do_softirq+0xa5/0x13a
> > > > [   56.816051]  [<ffffffff8100390c>] call_softirq+0x1c/0x28
> > > > [   56.816219]  [<ffffffff81004eba>] do_softirq+0x38/0x82
> > > > [   56.816385]  [<ffffffff8103c9e8>] irq_exit+0x47/0x49
> > > > [   56.816553]  [<ffffffff81019ce3>] smp_apic_timer_interrupt+0x88/0x96
> > > > [   56.816722]  [<ffffffff810033d3>] apic_timer_interrupt+0x13/0x20
> > > > [   56.816888]  <EOI>  [<ffffffff8138607a>] ? __atomic_notifier_call_chain+0x0/0x84
> > > > [   56.817215]  [<ffffffff81009a9b>] ? mwait_idle+0x65/0x71
> > > > [   56.817382]  [<ffffffff81009a91>] ? mwait_idle+0x5b/0x71
> > > > [   56.817549]  [<ffffffff810014ca>] cpu_idle+0x48/0x66
> > > > [   56.817716]  [<ffffffff8137b4da>] start_secondary+0x1b9/0x1bd
> > > > [   56.817883]  [<ffffffff8137b321>] ? start_secondary+0x0/0x1bd
> > > 
> > > Hello, Eric,
> > > 
> > > In linux/master, there is an rcu_read_lock_bh() in the call path, but
> > > an rcu_dereference() instead of an rcu_dereference_bh().  Thoughts?
> > > 
> > > (I have asked Andrew what kernel this is against -- I don't see the
> > > rcu_read_lock() that I would expect to see in the lockdep output.)
> > > 
> > > 							Thanx, Paul
> > 
> > This seems strange
> > 
> > include/linux/inetdevice.h:219
> > 
> > static inline struct in_device *__in_dev_get_rtnl(const struct net_device *dev)
> > {
> > 	return rcu_dereference_check(dev->ip_ptr, lockdep_rtnl_is_held());
> > }
> > 
> > But I dont think RTNL can possibly be held at this point ???
> > 
> > Oh wait, this is line 2582 in net/ipv4/route.c
> > 
> > It seems buggy and proud of it :)
> > 
> > 	/* RACE: Check return value of inet_select_addr instead. */ 
> > 	if (__in_dev_get_rtnl(dev_out) == NULL) {
> > 
> > This should be changed to 
> > 
> > 	if (rcu_dereference_raw(dev_out->ip_ptr) == NULL) {
> > 
> > No ?
> 
> You beat me to it.  ;-)
> 
> 							Thanx, Paul

OK, here is official submission to David then.

I based it against net-next-2.6.

Thanks

[PATCH net-next-2.6] net: fix rcu use in ip_route_output_slow

__in_dev_get_rtnl(dev_out) is called while RTNL is not held, thus
triggers a lockdep fault.

At this point, we only perform a raw test of dev_out->ip_ptr being NULL,
we dont need to make sure ip_ptr cant changed right after.

We can use rcu_dereference_raw() for this.

Reported-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
 net/ipv4/route.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index e24d48d..8d08377 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2579,7 +2579,7 @@ static int ip_route_output_slow(struct net *net, struct rtable **rp,
 			goto out;
 
 		/* RACE: Check return value of inet_select_addr instead. */
-		if (__in_dev_get_rtnl(dev_out) == NULL) {
+		if (rcu_dereference_raw(dev_out->ip_ptr) == NULL) {
 			dev_put(dev_out);
 			goto out;	/* Wrong error code */
 		}

Re: [PATCH net-next-2.6] net: fix rcu use in ip_route_output_slow

[David Miller]

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 24 Sep 2010 09:46:03 +0200

> [PATCH net-next-2.6] net: fix rcu use in ip_route_output_slow
> 
> __in_dev_get_rtnl(dev_out) is called while RTNL is not held, thus
> triggers a lockdep fault.
> 
> At this point, we only perform a raw test of dev_out->ip_ptr being NULL,
> we dont need to make sure ip_ptr cant changed right after.
> 
> We can use rcu_dereference_raw() for this.
> 
> Reported-by: Andrew Morton <akpm@linux-foundation.org>
> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>

Applied, thanks everyone!