lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 21 Apr 2010 14:35:43 -0700 From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> To: Miles Lane <miles.lane@...il.com> Cc: Eric Paris <eparis@...hat.com>, Lai Jiangshan <laijs@...fujitsu.com>, Ingo Molnar <mingo@...e.hu>, Peter Zijlstra <peterz@...radead.org>, LKML <linux-kernel@...r.kernel.org>, vgoyal@...hat.com, nauman@...gle.com, eric.dumazet@...il.com, netdev@...r.kernel.org Subject: Re: [PATCH] RCU: don't turn off lockdep when find suspicious rcu_dereference_check() usage On Tue, Apr 20, 2010 at 11:38:28AM -0400, Miles Lane wrote: > Excellent. Here are the results on my machine. .config appended. First, thank you very much for testing this, Miles! > [ 0.177300] [ INFO: suspicious rcu_dereference_check() usage. ] > [ 0.177428] --------------------------------------------------- > [ 0.177557] include/linux/cgroup.h:533 invoked > rcu_dereference_check() without protection! > [ 0.177760] > [ 0.177761] other info that might help us debug this: > [ 0.177762] > [ 0.178123] > [ 0.178124] rcu_scheduler_active = 1, debug_locks = 1 > [ 0.178369] no locks held by watchdog/0/5. > [ 0.178493] > [ 0.178494] stack backtrace: > [ 0.178735] Pid: 5, comm: watchdog/0 Not tainted 2.6.34-rc5 #18 > [ 0.178863] Call Trace: > [ 0.178994] [<ffffffff81067fc2>] lockdep_rcu_dereference+0x9d/0xa5 > [ 0.179127] [<ffffffff8102d667>] task_subsys_state+0x48/0x60 > [ 0.179259] [<ffffffff810328e5>] __sched_setscheduler+0x19d/0x300 > [ 0.179392] [<ffffffff8102b477>] ? need_resched+0x1e/0x28 > [ 0.179523] [<ffffffff813cd501>] ? schedule+0x643/0x66e > [ 0.179653] [<ffffffff81091903>] ? watchdog+0x0/0x8c > [ 0.179783] [<ffffffff81032a63>] sched_setscheduler+0xe/0x10 > [ 0.179913] [<ffffffff8109192d>] watchdog+0x2a/0x8c > [ 0.180010] [<ffffffff81091903>] ? watchdog+0x0/0x8c > [ 0.180142] [<ffffffff8105713e>] kthread+0x89/0x91 > [ 0.180272] [<ffffffff81068922>] ? trace_hardirqs_on_caller+0x114/0x13f > [ 0.180405] [<ffffffff81003994>] kernel_thread_helper+0x4/0x10 > [ 0.180537] [<ffffffff813cfcc0>] ? restore_args+0x0/0x30 > [ 0.180667] [<ffffffff810570b5>] ? kthread+0x0/0x91 > [ 0.180796] [<ffffffff81003990>] ? kernel_thread_helper+0x0/0x10 I have a prototype patch for this way down below, but someone who knows more about CONFIG_RT_GROUP_SCHED than I do should look it over. In the meantime, could you please see if it helps? > [ 3.116754] [ INFO: suspicious rcu_dereference_check() usage. ] > [ 3.116754] --------------------------------------------------- > [ 3.116754] kernel/cgroup.c:4432 invoked rcu_dereference_check() > without protection! > [ 3.116754] > [ 3.116754] other info that might help us debug this: > [ 3.116754] > [ 3.116754] > [ 3.116754] rcu_scheduler_active = 1, debug_locks = 1 > [ 3.116754] 2 locks held by async/1/666: > [ 3.116754] #0: (&shost->scan_mutex){+.+.+.}, at: > [<ffffffff812df0a0>] __scsi_add_device+0x83/0xe4 > [ 3.116754] #1: (&(&blkcg->lock)->rlock){......}, at: > [<ffffffff811f2e8d>] blkiocg_add_blkio_group+0x29/0x7f > [ 3.116754] > [ 3.116754] stack backtrace: > [ 3.116754] Pid: 666, comm: async/1 Not tainted 2.6.34-rc5 #18 > [ 3.116754] Call Trace: > [ 3.116754] [<ffffffff81067fc2>] lockdep_rcu_dereference+0x9d/0xa5 > [ 3.116754] [<ffffffff8107f9b1>] css_id+0x3f/0x51 > [ 3.116754] [<ffffffff811f2e9c>] blkiocg_add_blkio_group+0x38/0x7f > [ 3.116754] [<ffffffff811f4e64>] cfq_init_queue+0xdf/0x2dc > [ 3.116754] [<ffffffff811e3445>] elevator_init+0xba/0xf5 > [ 3.116754] [<ffffffff812dc02a>] ? scsi_request_fn+0x0/0x451 > [ 3.116754] [<ffffffff811e696b>] blk_init_queue_node+0x12f/0x135 > [ 3.116754] [<ffffffff811e697d>] blk_init_queue+0xc/0xe > [ 3.116754] [<ffffffff812dc49c>] __scsi_alloc_queue+0x21/0x111 > [ 3.116754] [<ffffffff812dc5a4>] scsi_alloc_queue+0x18/0x64 > [ 3.116754] [<ffffffff812de5a0>] scsi_alloc_sdev+0x19e/0x256 > [ 3.116754] [<ffffffff812de73e>] scsi_probe_and_add_lun+0xe6/0x9c5 > [ 3.116754] [<ffffffff81068922>] ? trace_hardirqs_on_caller+0x114/0x13f > [ 3.116754] [<ffffffff813ce0d6>] ? __mutex_lock_common+0x3e4/0x43a > [ 3.116754] [<ffffffff812df0a0>] ? __scsi_add_device+0x83/0xe4 > [ 3.116754] [<ffffffff812d0a5c>] ? transport_setup_classdev+0x0/0x17 > [ 3.116754] [<ffffffff812df0a0>] ? __scsi_add_device+0x83/0xe4 > [ 3.116754] [<ffffffff812df0d5>] __scsi_add_device+0xb8/0xe4 > [ 3.116754] [<ffffffff812ea9c5>] ata_scsi_scan_host+0x74/0x16e > [ 3.116754] [<ffffffff81057685>] ? autoremove_wake_function+0x0/0x34 > [ 3.116754] [<ffffffff812e8e64>] async_port_probe+0xab/0xb7 > [ 3.116754] [<ffffffff8105e1b5>] ? async_thread+0x0/0x1f4 > [ 3.116754] [<ffffffff8105e2ba>] async_thread+0x105/0x1f4 > [ 3.116754] [<ffffffff81033d79>] ? default_wake_function+0x0/0xf > [ 3.116754] [<ffffffff8105e1b5>] ? async_thread+0x0/0x1f4 > [ 3.116754] [<ffffffff8105713e>] kthread+0x89/0x91 > [ 3.116754] [<ffffffff81068922>] ? trace_hardirqs_on_caller+0x114/0x13f > [ 3.116754] [<ffffffff81003994>] kernel_thread_helper+0x4/0x10 > [ 3.116754] [<ffffffff813cfcc0>] ? restore_args+0x0/0x30 > [ 3.116754] [<ffffffff810570b5>] ? kthread+0x0/0x91 > [ 3.116754] [<ffffffff81003990>] ? kernel_thread_helper+0x0/0x10 I cannot convince myself that the above access is safe. Vivek, Nauman, thoughts? > [ 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. > [ 52.869375] [ INFO: suspicious rcu_dereference_check() usage. ] > [ 52.869378] --------------------------------------------------- > [ 52.869382] net/mac80211/sta_info.c:886 invoked > rcu_dereference_check() without protection! > [ 52.869386] > [ 52.869387] other info that might help us debug this: > [ 52.869389] > [ 52.869392] > [ 52.869392] rcu_scheduler_active = 1, debug_locks = 1 > [ 52.869397] 1 lock held by Xorg/4051: > [ 52.869399] #0: (&dev->struct_mutex){+.+.+.}, at: > [<ffffffff812afdc4>] i915_gem_do_execbuffer+0xf4c/0xfda > [ 52.869414] > [ 52.869415] stack backtrace: > [ 52.869420] Pid: 4051, comm: Xorg Not tainted 2.6.34-rc5 #18 > [ 52.869423] Call Trace: > [ 52.869426] <IRQ> [<ffffffff81067fc2>] lockdep_rcu_dereference+0x9d/0xa5 > [ 52.869454] [<ffffffffa01289ae>] > ieee80211_find_sta_by_hw+0x46/0x10f [mac80211] > [ 52.869467] [<ffffffffa0128a8e>] ieee80211_find_sta+0x17/0x19 [mac80211] > [ 52.869483] [<ffffffffa017a0f2>] iwl_tx_queue_reclaim+0xdb/0x1b1 [iwlcore] > [ 52.869490] [<ffffffff8106842f>] ? mark_lock+0x2d/0x235 > [ 52.869501] [<ffffffffa01a2f1c>] iwl5000_rx_reply_tx+0x4a9/0x556 [iwlagn] > [ 52.869508] [<ffffffff8120a3d3>] ? is_swiotlb_buffer+0x2e/0x3b > [ 52.869518] [<ffffffffa019bbf4>] iwl_rx_handle+0x163/0x2b5 [iwlagn] > [ 52.869524] [<ffffffff81068908>] ? trace_hardirqs_on_caller+0xfa/0x13f > [ 52.869534] [<ffffffffa019c3ac>] iwl_irq_tasklet+0x2bb/0x3c0 [iwlagn] > [ 52.869540] [<ffffffff810411df>] tasklet_action+0xa7/0x10f > [ 52.869546] [<ffffffff810421f1>] __do_softirq+0x144/0x252 > [ 52.869553] [<ffffffff81003a8c>] call_softirq+0x1c/0x34 > [ 52.869559] [<ffffffff810050e4>] do_softirq+0x38/0x80 > [ 52.869564] [<ffffffff81041cbe>] irq_exit+0x45/0x94 > [ 52.869569] [<ffffffff81004829>] do_IRQ+0xad/0xc4 > [ 52.869576] [<ffffffff813cfc13>] ret_from_intr+0x0/0xf > [ 52.869580] <EOI> [<ffffffff81068765>] ? lockdep_trace_alloc+0xbe/0xc2 > [ 52.869592] [<ffffffff810bca55>] __alloc_pages_nodemask+0x8f/0x6a5 > [ 52.869598] [<ffffffff810b70f5>] ? rcu_read_lock+0x0/0x35 > [ 52.869604] [<ffffffff810b70f5>] ? rcu_read_lock+0x0/0x35 > [ 52.869610] [<ffffffff810c33cb>] ? kmap_atomic+0x16/0x4b > [ 52.869615] [<ffffffff810b71ad>] ? rcu_read_unlock+0x21/0x23 > [ 52.869621] [<ffffffff810b6c3c>] __page_cache_alloc+0x14/0x16 > [ 52.869627] [<ffffffff810b836d>] do_read_cache_page+0x43/0x121 > [ 52.869632] [<ffffffff810c54bd>] ? shmem_readpage+0x0/0x3c > [ 52.869638] [<ffffffff810b8464>] read_cache_page_gfp+0x19/0x23 > [ 52.869644] [<ffffffff812aac10>] i915_gem_object_get_pages+0xa1/0x115 > [ 52.869651] [<ffffffff812ad23e>] i915_gem_object_bind_to_gtt+0x16d/0x2ce > [ 52.869657] [<ffffffff812ad3c6>] i915_gem_object_pin+0x27/0x88 > [ 52.869663] [<ffffffff812af316>] i915_gem_do_execbuffer+0x49e/0xfda > [ 52.869670] [<ffffffff810cbb93>] ? might_fault+0x63/0xb3 > [ 52.869676] [<ffffffff810cbbdc>] ? might_fault+0xac/0xb3 > [ 52.869681] [<ffffffff810cbb93>] ? might_fault+0x63/0xb3 > [ 52.869687] [<ffffffff812b010d>] i915_gem_execbuffer+0x192/0x221 > [ 52.869694] [<ffffffff812900d0>] drm_ioctl+0x25a/0x36e > [ 52.869700] [<ffffffff812aff7b>] ? i915_gem_execbuffer+0x0/0x221 > [ 52.869707] [<ffffffff810e9ad1>] ? do_sync_read+0xc6/0x103 > [ 52.869714] [<ffffffff810f6dcd>] vfs_ioctl+0x2d/0xa1 > [ 52.869720] [<ffffffff810f7343>] do_vfs_ioctl+0x48b/0x4d1 > [ 52.869726] [<ffffffff810f73da>] sys_ioctl+0x51/0x74 > [ 52.869733] [<ffffffff81002b6b>] system_call_fastpath+0x16/0x1b This one looks to be an update-side reference protected by dev->struct_mutex, but there is no obvious way to get that information to the pair of rcu_dereference() calls in for_each_sta_info(). Besides which, I am not 100% certain that this one is really only a false positive. Especially given that the next one looks similar, but uses a different lock. Eric, and enlightenment? > [ 52.884563] [ INFO: suspicious rcu_dereference_check() usage. ] > [ 52.884566] --------------------------------------------------- > [ 52.884571] net/mac80211/sta_info.c:886 invoked > rcu_dereference_check() without protection! > [ 52.884574] > [ 52.884575] other info that might help us debug this: > [ 52.884577] > [ 52.884580] > [ 52.884581] rcu_scheduler_active = 1, debug_locks = 1 > [ 52.884585] 1 lock held by rsyslogd/3854: > [ 52.884588] #0: (&sb->s_type->i_mutex_key#10){+.+.+.}, at: > [<ffffffff810b7f97>] generic_file_aio_write+0x47/0xa8 > [ 52.884604] > [ 52.884605] stack backtrace: > [ 52.884610] Pid: 3854, comm: rsyslogd Not tainted 2.6.34-rc5 #18 > [ 52.884613] Call Trace: > [ 52.884617] <IRQ> [<ffffffff81067fc2>] lockdep_rcu_dereference+0x9d/0xa5 > [ 52.884645] [<ffffffffa01289fe>] > ieee80211_find_sta_by_hw+0x96/0x10f [mac80211] > [ 52.884658] [<ffffffffa0128a8e>] ieee80211_find_sta+0x17/0x19 [mac80211] > [ 52.884675] [<ffffffffa017a0f2>] iwl_tx_queue_reclaim+0xdb/0x1b1 [iwlcore] > [ 52.884681] [<ffffffff8106842f>] ? mark_lock+0x2d/0x235 > [ 52.884693] [<ffffffffa01a2f1c>] iwl5000_rx_reply_tx+0x4a9/0x556 [iwlagn] > [ 52.884701] [<ffffffff8120a3d3>] ? is_swiotlb_buffer+0x2e/0x3b > [ 52.884710] [<ffffffffa019bbf4>] iwl_rx_handle+0x163/0x2b5 [iwlagn] > [ 52.884717] [<ffffffff81068908>] ? trace_hardirqs_on_caller+0xfa/0x13f > [ 52.884726] [<ffffffffa019c3ac>] iwl_irq_tasklet+0x2bb/0x3c0 [iwlagn] > [ 52.884733] [<ffffffff810411df>] tasklet_action+0xa7/0x10f > [ 52.884739] [<ffffffff810421f1>] __do_softirq+0x144/0x252 > [ 52.884746] [<ffffffff81003a8c>] call_softirq+0x1c/0x34 > [ 52.884752] [<ffffffff810050e4>] do_softirq+0x38/0x80 > [ 52.884757] [<ffffffff81041cbe>] irq_exit+0x45/0x94 > [ 52.884762] [<ffffffff81004829>] do_IRQ+0xad/0xc4 > [ 52.884769] [<ffffffff813cfc13>] ret_from_intr+0x0/0xf > [ 52.884773] <EOI> [<ffffffff810e3509>] ? kmem_cache_free+0xb0/0x134 > [ 52.884789] [<ffffffff811913dc>] ? jbd2_journal_stop+0x32c/0x33e > [ 52.884796] [<ffffffff811913dc>] jbd2_journal_stop+0x32c/0x33e > [ 52.884804] [<ffffffff8115e689>] ? ext4_dirty_inode+0x40/0x45 > [ 52.884811] [<ffffffff81105fdb>] ? __mark_inode_dirty+0x2f/0x12e > [ 52.884819] [<ffffffff81170a65>] __ext4_journal_stop+0x6f/0x75 > [ 52.884825] [<ffffffff81162949>] ext4_da_write_end+0x25c/0x2fc > [ 52.884833] [<ffffffff810b6b2e>] generic_file_buffered_write+0x161/0x25b > [ 52.884840] [<ffffffff810b7f1b>] __generic_file_aio_write+0x24a/0x27f > [ 52.884845] [<ffffffff810b7f97>] ? generic_file_aio_write+0x47/0xa8 > [ 52.884852] [<ffffffff810b7faa>] generic_file_aio_write+0x5a/0xa8 > [ 52.884858] [<ffffffff8115ab2a>] ext4_file_write+0x8c/0x96 > [ 52.884864] [<ffffffff810e99ce>] do_sync_write+0xc6/0x103 > [ 52.884871] [<ffffffff810eac6d>] ? rcu_read_lock+0x0/0x35 > [ 52.884878] [<ffffffff811c17db>] ? selinux_file_permission+0x57/0xaf > [ 52.884885] [<ffffffff811bb085>] ? security_file_permission+0x11/0x13 > [ 52.884893] [<ffffffff810e9f33>] vfs_write+0xa9/0x106 > [ 52.884898] [<ffffffff810ea046>] sys_write+0x45/0x69 > [ 52.884905] [<ffffffff81002b6b>] system_call_fastpath+0x16/0x1b Ditto! > [ 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? > [ 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@...ux.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@...ux.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 netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists