* Fw: rcu warning @ 2010-09-22 21:44 Paul E. McKenney 2010-09-22 21:47 ` Andrew Morton 2010-09-22 23:04 ` Eric Dumazet 0 siblings, 2 replies; 7+ messages in thread From: Paul E. McKenney @ 2010-09-22 21:44 UTC (permalink / raw) To: eric.dumazet; +Cc: akpm, netdev > 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 ----- ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fw: rcu warning 2010-09-22 21:44 Fw: rcu warning Paul E. McKenney @ 2010-09-22 21:47 ` Andrew Morton 2010-09-22 23:11 ` Paul E. McKenney 2010-09-22 23:04 ` Eric Dumazet 1 sibling, 1 reply; 7+ messages in thread From: Andrew Morton @ 2010-09-22 21:47 UTC (permalink / raw) To: paulmck; +Cc: eric.dumazet, netdev 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fw: rcu warning 2010-09-22 21:47 ` Andrew Morton @ 2010-09-22 23:11 ` Paul E. McKenney 0 siblings, 0 replies; 7+ messages in thread From: Paul E. McKenney @ 2010-09-22 23:11 UTC (permalink / raw) To: Andrew Morton; +Cc: eric.dumazet, netdev 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fw: rcu warning 2010-09-22 21:44 Fw: rcu warning Paul E. McKenney 2010-09-22 21:47 ` Andrew Morton @ 2010-09-22 23:04 ` Eric Dumazet 2010-09-22 23:12 ` Paul E. McKenney 1 sibling, 1 reply; 7+ messages in thread From: Eric Dumazet @ 2010-09-22 23:04 UTC (permalink / raw) To: paulmck; +Cc: akpm, netdev 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 */ } ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: Fw: rcu warning 2010-09-22 23:04 ` Eric Dumazet @ 2010-09-22 23:12 ` Paul E. McKenney 2010-09-24 7:46 ` [PATCH net-next-2.6] net: fix rcu use in ip_route_output_slow Eric Dumazet 0 siblings, 1 reply; 7+ messages in thread From: Paul E. McKenney @ 2010-09-22 23:12 UTC (permalink / raw) To: Eric Dumazet; +Cc: akpm, netdev 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH net-next-2.6] net: fix rcu use in ip_route_output_slow 2010-09-22 23:12 ` Paul E. McKenney @ 2010-09-24 7:46 ` Eric Dumazet 2010-09-27 2:05 ` David Miller 0 siblings, 1 reply; 7+ messages in thread From: Eric Dumazet @ 2010-09-24 7:46 UTC (permalink / raw) To: paulmck, David Miller; +Cc: akpm, netdev 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 */ } ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH net-next-2.6] net: fix rcu use in ip_route_output_slow 2010-09-24 7:46 ` [PATCH net-next-2.6] net: fix rcu use in ip_route_output_slow Eric Dumazet @ 2010-09-27 2:05 ` David Miller 0 siblings, 0 replies; 7+ messages in thread From: David Miller @ 2010-09-27 2:05 UTC (permalink / raw) To: eric.dumazet; +Cc: paulmck, akpm, netdev 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! ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-09-27 2:05 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-09-22 21:44 Fw: rcu warning Paul E. McKenney 2010-09-22 21:47 ` Andrew Morton 2010-09-22 23:11 ` Paul E. McKenney 2010-09-22 23:04 ` Eric Dumazet 2010-09-22 23:12 ` Paul E. McKenney 2010-09-24 7:46 ` [PATCH net-next-2.6] net: fix rcu use in ip_route_output_slow Eric Dumazet 2010-09-27 2:05 ` David Miller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).