Prev: uml: Remove unused variable from line driver
Next: [PATCH] Mass Storage Gadget: Handle eject request
From: Paul E. McKenney on 21 Apr 2010 18:20
On Wed, Apr 21, 2010 at 11:57:09PM +0200, Eric Dumazet wrote:
> Le mercredi 21 avril 2010 � 14:35 -0700, Paul E. McKenney a �crit :
>
> > > [ 33.425087] [ INFO: suspicious rcu_dereference_check() usage. ]
> > > [ 33.425090] ---------------------------------------------------
> > > [ 33.425094] net/core/dev.c:1993 invoked rcu_dereference_check()
> > > without protection!
> > > [ 33.425098]
> > > [ 33.425098] other info that might help us debug this:
> > > [ 33.425100]
> > > [ 33.425103]
> > > [ 33.425104] rcu_scheduler_active = 1, debug_locks = 1
> > > [ 33.425108] 2 locks held by canberra-gtk-pl/4208:
> > > [ 33.425111] #0: (sk_lock-AF_INET){+.+.+.}, at:
> > > [<ffffffff81394ffd>] inet_stream_connect+0x3a/0x24d
> > > [ 33.425125] #1: (rcu_read_lock_bh){.+....}, at:
> > > [<ffffffff8134a809>] dev_queue_xmit+0x14e/0x4b8
> > > [ 33.425137]
> > > [ 33.425138] stack backtrace:
> > > [ 33.425142] Pid: 4208, comm: canberra-gtk-pl Not tainted 2.6.34-rc5 #18
> > > [ 33.425146] Call Trace:
> > > [ 33.425154] [<ffffffff81067fc2>] lockdep_rcu_dereference+0x9d/0xa5
> > > [ 33.425161] [<ffffffff8134a914>] dev_queue_xmit+0x259/0x4b8
> > > [ 33.425167] [<ffffffff8134a809>] ? dev_queue_xmit+0x14e/0x4b8
> > > [ 33.425173] [<ffffffff81041c52>] ? _local_bh_enable_ip+0xcd/0xda
> > > [ 33.425180] [<ffffffff8135375a>] neigh_resolve_output+0x234/0x285
> > > [ 33.425188] [<ffffffff8136f71f>] ip_finish_output2+0x257/0x28c
> > > [ 33.425193] [<ffffffff8136f7bc>] ip_finish_output+0x68/0x6a
> > > [ 33.425198] [<ffffffff813704b3>] T.866+0x52/0x59
> > > [ 33.425203] [<ffffffff813706fe>] ip_output+0xaa/0xb4
> > > [ 33.425209] [<ffffffff8136ebb8>] ip_local_out+0x20/0x24
> > > [ 33.425215] [<ffffffff8136f204>] ip_queue_xmit+0x309/0x368
> > > [ 33.425223] [<ffffffff810e41e6>] ? __kmalloc_track_caller+0x111/0x155
> > > [ 33.425230] [<ffffffff813831ef>] ? tcp_connect+0x223/0x3d3
> > > [ 33.425236] [<ffffffff81381971>] tcp_transmit_skb+0x707/0x745
> > > [ 33.425243] [<ffffffff81383342>] tcp_connect+0x376/0x3d3
> > > [ 33.425250] [<ffffffff81268ac3>] ? secure_tcp_sequence_number+0x55/0x6f
> > > [ 33.425256] [<ffffffff813872f0>] tcp_v4_connect+0x3df/0x455
> > > [ 33.425263] [<ffffffff8133cbd9>] ? lock_sock_nested+0xf3/0x102
> > > [ 33.425269] [<ffffffff81395067>] inet_stream_connect+0xa4/0x24d
> > > [ 33.425276] [<ffffffff8133b418>] sys_connect+0x90/0xd0
> > > [ 33.425283] [<ffffffff81002b9c>] ? sysret_check+0x27/0x62
> > > [ 33.425289] [<ffffffff81068922>] ? trace_hardirqs_on_caller+0x114/0x13f
> > > [ 33.425296] [<ffffffff813ced00>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> > > [ 33.425303] [<ffffffff81002b6b>] system_call_fastpath+0x16/0x1b
> >
> > This looks like an rcu_dereference() needs to instead be
> > rcu_dereference_bh(), but the line numbering in my version of
> > net/core/dev.c does not match yours. CCing netdev, hopefully
> > someone there will know which rcu_dereference() is indicated.
>
> This is already sorted out in David trees

Very good!!! ;-)

> > > [ 85.939528] [ INFO: suspicious rcu_dereference_check() usage. ]
> > > [ 85.939531] ---------------------------------------------------
> > > [ 85.939535] include/net/inet_timewait_sock.h:227 invoked
> > > rcu_dereference_check() without protection!
> > > [ 85.939539]
> > > [ 85.939540] other info that might help us debug this:
> > > [ 85.939541]
> > > [ 85.939544]
> > > [ 85.939545] rcu_scheduler_active = 1, debug_locks = 1
> > > [ 85.939549] 2 locks held by gwibber-service/4798:
> > > [ 85.939552] #0: (&p->lock){+.+.+.}, at: [<ffffffff811034b2>]
> > > seq_read+0x37/0x381
> > > [ 85.939566] #1: (&(&hashinfo->ehash_locks[i])->rlock){+.-...},
> > > at: [<ffffffff81386355>] established_get_next+0xc4/0x132
> > > [ 85.939579]
> > > [ 85.939580] stack backtrace:
> > > [ 85.939585] Pid: 4798, comm: gwibber-service Not tainted 2.6.34-rc5 #18
> > > [ 85.939588] Call Trace:
> > > [ 85.939598] [<ffffffff81067fc2>] lockdep_rcu_dereference+0x9d/0xa5
> > > [ 85.939604] [<ffffffff81385018>] twsk_net+0x4f/0x57
> > > [ 85.939610] [<ffffffff813862e5>] established_get_next+0x54/0x132
> > > [ 85.939615] [<ffffffff813864c7>] tcp_seq_next+0x5d/0x6a
> > > [ 85.939621] [<ffffffff81103701>] seq_read+0x286/0x381
> > > [ 85.939627] [<ffffffff8110347b>] ? seq_read+0x0/0x381
> > > [ 85.939633] [<ffffffff81133240>] proc_reg_read+0x8d/0xac
> > > [ 85.939640] [<ffffffff810ea110>] vfs_read+0xa6/0x103
> > > [ 85.939645] [<ffffffff810ea223>] sys_read+0x45/0x69
> > > [ 85.939652] [<ffffffff81002b6b>] system_call_fastpath+0x16/0x1b
> >
> > This one appears to be a case of missing rcu_read_lock(), but it is
> > not clear to me at what level it needs to go.
> >
> > Eric, any enlightenment on this one and the next one?
>
> Coming from commit b099ce2602d806deb41caaa578731848995cdb2a
> >From Eric Biederman (CCed)
>
> Apparently he added rcu to twsk_net(), but Changelog doesnt mention it.

Thank you for chasing this down, Eric Dumazet!

Eric Biederman, any enlightment?

Thanx, Paul

> > > [ 87.296366] [ INFO: suspicious rcu_dereference_check() usage. ]
> > > [ 87.296369] ---------------------------------------------------
> > > [ 87.296373] include/net/inet_timewait_sock.h:227 invoked
> > > rcu_dereference_check() without protection!
> > > [ 87.296377]
> > > [ 87.296377] other info that might help us debug this:
> > > [ 87.296379]
> > > [ 87.296382]
> > > [ 87.296383] rcu_scheduler_active = 1, debug_locks = 1
> > > [ 87.296386] no locks held by gwibber-service/4803.
> > > [ 87.296389]
> > > [ 87.296390] stack backtrace:
> > > [ 87.296395] Pid: 4803, comm: gwibber-service Not tainted 2.6.34-rc5 #18
> > > [ 87.296398] Call Trace:
> > > [ 87.296411] [<ffffffff81067fc2>] lockdep_rcu_dereference+0x9d/0xa5
> > > [ 87.296419] [<ffffffff813733d3>] twsk_net+0x4f/0x57
> > > [ 87.296424] [<ffffffff813737f3>] __inet_twsk_hashdance+0x50/0x158
> > > [ 87.296431] [<ffffffff81389239>] tcp_time_wait+0x1c1/0x24b
> > > [ 87.296437] [<ffffffff8137c417>] tcp_fin+0x83/0x162
> > > [ 87.296443] [<ffffffff8137cda7>] tcp_data_queue+0x1ff/0xa1e
> > > [ 87.296450] [<ffffffff810495c6>] ? mod_timer+0x1e/0x20
> > > [ 87.296456] [<ffffffff813809e3>] tcp_rcv_state_process+0x89d/0x8f2
> > > [ 87.296463] [<ffffffff8133ca0b>] ? release_sock+0x30/0x10b
> > > [ 87.296468] [<ffffffff81386df2>] tcp_v4_do_rcv+0x2de/0x33f
> > > [ 87.296475] [<ffffffff8133ca5d>] release_sock+0x82/0x10b
> > > [ 87.296481] [<ffffffff81376ef5>] tcp_close+0x1b5/0x37e
> > > [ 87.296487] [<ffffffff81395437>] inet_release+0x50/0x57
> > > [ 87.296493] [<ffffffff8133a134>] sock_release+0x1a/0x66
> > > [ 87.296498] [<ffffffff8133a1a2>] sock_close+0x22/0x26
> > > [ 87.296505] [<ffffffff810eb003>] __fput+0x120/0x1cd
> > > [ 87.296510] [<ffffffff810eb0c5>] fput+0x15/0x17
> > > [ 87.296516] [<ffffffff810e7f3d>] filp_close+0x63/0x6d
> > > [ 87.296521] [<ffffffff810e801e>] sys_close+0xd7/0x111
> > > [ 87.296528] [<ffffffff81002b6b>] system_call_fastpath+0x16/0x1b
> >
> > commit d3b8ba1bde9afb7d50cf0712f9d95317ea66c06f
> > Author: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
> > Date: Wed Apr 21 14:04:56 2010 -0700
> >
> > sched: protect __sched_setscheduler() access to cgroups
> >
> > A given task's cgroups structures must remain while that task is running
> > due to reference counting, so this is presumably a false positive.
> >
> > Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
> >
> > diff --git a/kernel/sched.c b/kernel/sched.c
> > index 14c44ec..1d43c1a 100644
> > --- a/kernel/sched.c
> > +++ b/kernel/sched.c
> > @@ -4575,9 +4575,11 @@ recheck:
> > * Do not allow realtime tasks into groups that have no runtime
> > * assigned.
> > */
> > + rcu_read_lock();
> > if (rt_bandwidth_enabled() && rt_policy(policy) &&
> > task_group(p)->rt_bandwidth.rt_runtime == 0)
> > return -EPERM;
> > + rcu_read_unlock();
> > #endif
> >
> > retval = security_task_setscheduler(p, policy, param);
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo(a)vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on 24 Apr 2010 22:40
On Sat, Apr 24, 2010 at 01:35:01AM -0400, Miles Lane wrote:
> 2.6.34-rc5-git5 with all of your patches applied.
>
> I reconfigured my kernel build options and got the following new issue:
>
> [ 2.686515] [ INFO: suspicious rcu_dereference_check() usage. ]
> [ 2.686519] ---------------------------------------------------
> [ 2.686523] kernel/cgroup.c:4438 invoked rcu_dereference_check()
> without protection!
> [ 2.686526]
> [ 2.686527] other info that might help us debug this:
> [ 2.686529]
> [ 2.686532]
> [ 2.686533] rcu_scheduler_active = 1, debug_locks = 1
> [ 2.686537] 2 locks held by swapper/1:
> [ 2.686540] #0: (mtd_table_mutex){+.+.+.}, at:
> [<ffffffff812d7714>] register_mtd_blktrans+0xa2/0x25e
> [ 2.686555] #1: (&(&blkcg->lock)->rlock){......}, at:
> [<ffffffff811ca7bd>] blkiocg_add_blkio_group+0x29/0x7f
> [ 2.686566]
> [ 2.686567] stack backtrace:
> [ 2.686572] Pid: 1, comm: swapper Not tainted 2.6.34-rc5-git5 #25
> [ 2.686576] Call Trace:
> [ 2.686584] [<ffffffff810642da>] lockdep_rcu_dereference+0x9d/0xa5
> [ 2.686591] [<ffffffff8107af54>] css_id+0x3f/0x52
> [ 2.686597] [<ffffffff811ca7cc>] blkiocg_add_blkio_group+0x38/0x7f
> [ 2.686603] [<ffffffff811cc593>] cfq_init_queue+0xdf/0x2dc
> [ 2.686609] [<ffffffff811bb858>] elevator_init+0xba/0xf5
> [ 2.686616] [<ffffffff812d7046>] ? mtd_blktrans_request+0x0/0x1c
> [ 2.686623] [<ffffffff811c0b62>] blk_init_queue_node+0x12f/0x135
> [ 2.686629] [<ffffffff811c0b74>] blk_init_queue+0xc/0xe
> [ 2.686635] [<ffffffff812d7777>] register_mtd_blktrans+0x105/0x25e
> [ 2.686642] [<ffffffff818c0de9>] ? init_mtdblock+0x0/0x2c
> [ 2.686648] [<ffffffff818c0e13>] init_mtdblock+0x2a/0x2c
> [ 2.686656] [<ffffffff810001ef>] do_one_initcall+0x59/0x14e
> [ 2.686663] [<ffffffff818986a6>] kernel_init+0x160/0x1ea
> [ 2.686669] [<ffffffff81003814>] kernel_thread_helper+0x4/0x10
> [ 2.686677] [<ffffffff8140d77c>] ? restore_args+0x0/0x30
> [ 2.686683] [<ffffffff81898546>] ? kernel_init+0x0/0x1ea
> [ 2.686688] [<ffffffff81003810>] ? kernel_thread_helper+0x0/0x10
> [ 2.687683] mtdoops: mtd device (mtddev=name/number) must be supplied

This should be covered by the patch I sent with my previous email.

And thank you again, Miles, for all the testing!!!

Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 25 Apr 2010 03:50
From: Johannes Berg <johannes(a)sipsolutions.net>
Date: Sun, 25 Apr 2010 09:45:34 +0200

> The station locking is a tad confusing, but I've added the right
> annotations already, should be coming to a kernel near you soon (i.e.
> are in net-2.6 right now).

Linus took in everything I have so it should be in Linus's tree
by now.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Johannes Berg on 25 Apr 2010 03:50
On Sat, 2010-04-24 at 19:34 -0700, Paul E. McKenney wrote:

> > [ 51.912282] [ INFO: suspicious rcu_dereference_check() usage. ]
> > [ 51.912285] ---------------------------------------------------
> > [ 51.912289] net/mac80211/sta_info.c:886 invoked
> > rcu_dereference_check() without protection!
> > [ 51.912293]
> > [ 51.912293] other info that might help us debug this:
> > [ 51.912295]
> > [ 51.912298]
> > [ 51.912298] rcu_scheduler_active = 1, debug_locks = 1
> > [ 51.912302] no locks held by wpa_supplicant/3951.
> > [ 51.912305]
> > [ 51.912306] stack backtrace:
> > [ 51.912310] Pid: 3951, comm: wpa_supplicant Not tainted 2.6.34-rc5-git3 #22
> > [ 51.912314] Call Trace:
> > [ 51.912317] <IRQ> [<ffffffff81067fbe>] lockdep_rcu_dereference+0x9d/0xa5
> > [ 51.912345] [<ffffffffa014f9ae>]
> > ieee80211_find_sta_by_hw+0x46/0x10f [mac80211]
> > [ 51.912358] [<ffffffffa014fa8e>] ieee80211_find_sta+0x17/0x19 [mac80211]
> > [ 51.912373] [<ffffffffa01e50f2>] iwl_tx_queue_reclaim+0xdb/0x1b1 [iwlcore]
> > [ 51.912380] [<ffffffff8106842b>] ? mark_lock+0x2d/0x235
> > [ 51.912391] [<ffffffffa0252f1c>] iwl5000_rx_reply_tx+0x4a9/0x556 [iwlagn]
> > [ 51.912399] [<ffffffff8120a353>] ? is_swiotlb_buffer+0x2e/0x3b
> > [ 51.912407] [<ffffffffa024bbf4>] iwl_rx_handle+0x163/0x2b5 [iwlagn]
> > [ 51.912414] [<ffffffff81068904>] ? trace_hardirqs_on_caller+0xfa/0x13f
> > [ 51.912422] [<ffffffffa024c3ac>] iwl_irq_tasklet+0x2bb/0x3c0 [iwlagn]
> > [ 51.912429] [<ffffffff810411f3>] tasklet_action+0xa7/0x10f
> > [ 51.912435] [<ffffffff81042205>] __do_softirq+0x144/0x252
> > [ 51.912442] [<ffffffff81003a8c>] call_softirq+0x1c/0x34
> > [ 51.912447] [<ffffffff810050e4>] do_softirq+0x38/0x80
> > [ 51.912452] [<ffffffff81041cd2>] irq_exit+0x45/0x94
> > [ 51.912457] [<ffffffff81004829>] do_IRQ+0xad/0xc4
> > [ 51.912463] [<ffffffff810cbbd3>] ? might_fault+0x63/0xb3
> > [ 51.912470] [<ffffffff813cfb93>] ret_from_intr+0x0/0xf
> > [ 51.912474] <EOI> [<ffffffff810cbbd3>] ? might_fault+0x63/0xb3
> > [ 51.912484] [<ffffffff8106a75d>] ? lock_release+0x208/0x215
> > [ 51.912490] [<ffffffff810cbc1c>] might_fault+0xac/0xb3
> > [ 51.912495] [<ffffffff810cbbd3>] ? might_fault+0x63/0xb3
> > [ 51.912501] [<ffffffff812025e3>] __clear_user+0x15/0x59
> > [ 51.912508] [<ffffffff8100b2bc>] save_i387_xstate+0x9c/0x1bc
> > [ 51.912515] [<ffffffff81002276>] do_signal+0x240/0x686
> > [ 51.912521] [<ffffffff81002b9c>] ? sysret_check+0x27/0x62
> > [ 51.912527] [<ffffffff8106891e>] ? trace_hardirqs_on_caller+0x114/0x13f
> > [ 51.912533] [<ffffffff813cec80>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> > [ 51.912539] [<ffffffff810026e3>] do_notify_resume+0x27/0x5f
> > [ 51.912545] [<ffffffff813cec80>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> > [ 51.912551] [<ffffffff81002e86>] int_signal+0x12/0x17
>
> This is a repeat from last time that confused me at the time. I could
> do a hacky "fix" by putting an RCU read-side critical section around
> the for_each_sta_info() in ieee80211_find_sta_by_hw(), but I do not
> understand this code well enough to feel comfortable doing so.
>
> Johannes, any enlightenment?

The station locking is a tad confusing, but I've added the right
annotations already, should be coming to a kernel near you soon (i.e.
are in net-2.6 right now).

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Paul E. McKenney on 25 Apr 2010 22:10
On Sun, Apr 25, 2010 at 12:49:25AM -0700, David Miller wrote:
> From: Johannes Berg <johannes(a)sipsolutions.net>
> Date: Sun, 25 Apr 2010 09:45:34 +0200
>
> > The station locking is a tad confusing, but I've added the right
> > annotations already, should be coming to a kernel near you soon (i.e.
> > are in net-2.6 right now).
>
> Linus took in everything I have so it should be in Linus's tree
> by now.

Thank you both, Dave and Johannes!

Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: uml: Remove unused variable from line driver
Next: [PATCH] Mass Storage Gadget: Handle eject request