Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 27 4月, 2011 1 次提交
  3. 05 4月, 2011 1 次提交
  5. 01 3月, 2011 1 次提交
    • A
      rtlwifi: Add the missing rcu_read_lock/unlock · 701c2be0
      由 Alessio Igor Bogani 提交于 
      ===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
net/mac80211/sta_info.c:125 invoked rcu_dereference_check() without protection!

other info that might help us debug this:

rcu_scheduler_active = 1, debug_locks = 0
5 locks held by wpa_supplicant/468:
 #0:  (rtnl_mutex){+.+.+.}, at: [<c1465d84>] rtnl_lock+0x14/0x20
 #1:  (&rdev->mtx){+.+.+.}, at: [<f84b8c2b>] cfg80211_mgd_wext_siwfreq+0x6b/0x170 [cfg80211]
 #2:  (&rdev->devlist_mtx){+.+.+.}, at: [<f84b8c37>] cfg80211_mgd_wext_siwfreq+0x77/0x170 [cfg80211]
 #3:  (&wdev->mtx){+.+.+.}, at: [<f84b8c44>] cfg80211_mgd_wext_siwfreq+0x84/0x170 [cfg80211]
 #4:  (&rtlpriv->locks.conf_mutex){+.+.+.}, at: [<f8506476>] rtl_op_bss_info_changed+0x26/0xc10 [rtlwifi]

stack backtrace:
Pid: 468, comm: wpa_supplicant Not tainted 2.6.38-rc6+ #79
Call Trace:
 [<c108806a>] ? lockdep_rcu_dereference+0xaa/0xb0
 [<f8523d2c>] ? sta_info_get_bss+0x19c/0x1b0 [mac80211]
 [<f8523d62>] ? ieee80211_find_sta+0x22/0x40 [mac80211]
 [<f850661c>] ? rtl_op_bss_info_changed+0x1cc/0xc10 [rtlwifi]
 [<c153671c>] ? __mutex_unlock_slowpath+0x14c/0x160
 [<c153673d>] ? mutex_unlock+0xd/0x10
 [<f8507180>] ? rtl_op_config+0x120/0x310 [rtlwifi]
 [<c10896db>] ? trace_hardirqs_on+0xb/0x10
 [<f8522169>] ? ieee80211_bss_info_change_notify+0xf9/0x1f0 [mac80211]
 [<f8506450>] ? rtl_op_bss_info_changed+0x0/0xc10 [rtlwifi]
 [<f853646f>] ? ieee80211_set_channel+0xbf/0xd0 [mac80211]
 [<f84b5f41>] ? cfg80211_set_freq+0x121/0x180 [cfg80211]
 [<f85363b0>] ? ieee80211_set_channel+0x0/0xd0 [mac80211]
 [<f84b8ceb>] ? cfg80211_mgd_wext_siwfreq+0x12b/0x170 [cfg80211]
 [<f84b87eb>] ? cfg80211_wext_siwfreq+0x9b/0x100 [cfg80211]
 [<c153b98b>] ? sub_preempt_count+0x7b/0xb0
 [<c150f874>] ? ioctl_standard_call+0x74/0x3b0
 [<c1465d84>] ? rtnl_lock+0x14/0x20
 [<f84b8750>] ? cfg80211_wext_siwfreq+0x0/0x100 [cfg80211]
 [<c14568bd>] ? __dev_get_by_name+0x8d/0xb0
 [<c150fddb>] ? wext_handle_ioctl+0x16b/0x180
 [<f84b8750>] ? cfg80211_wext_siwfreq+0x0/0x100 [cfg80211]
 [<c145bc7a>] ? dev_ioctl+0x5ba/0x720
 [<c108a947>] ? __lock_acquire+0x3e7/0x19b0
 [<c1443b0b>] ? sock_ioctl+0x1eb/0x290
 [<c108bfa5>] ? lock_release_non_nested+0x95/0x2f0
 [<c1443920>] ? sock_ioctl+0x0/0x290
 [<c114d74d>] ? do_vfs_ioctl+0x7d/0x5c0
 [<c1112232>] ? might_fault+0x62/0xb0
 [<c113e3c6>] ? fget_light+0x226/0x390
 [<c1112278>] ? might_fault+0xa8/0xb0
 [<c114dd17>] ? sys_ioctl+0x87/0x90
 [<c1002f9f>] ? sysenter_do_call+0x12/0x38

This work was supported by a hardware donation from the CE Linux Forum.
Signed-off-by: NAlessio Igor Bogani <abogani@kernel.org>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      701c2be0
  7. 26 2月, 2011 1 次提交
    • J
      mac80211: make tx() operation return void · 7bb45683
      由 Johannes Berg 提交于 
      The return value of the tx operation is commonly
misused by drivers, leading to errors. All drivers
will drop frames if they fail to TX the frame, and
they must also properly manage the queues (if they
didn't, mac80211 would already warn).

Removing the ability for drivers to return a BUSY
value also allows significant cleanups of the TX
TX handling code in mac80211.

Note that this also fixes a bug in ath9k_htc, the
old "return -1" there was wrong.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Tested-by: Sedat Dilek <sedat.dilek@googlemail.com> [ath5k]
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> [rt2x00]
Acked-by: Larry Finger <Larry.Finger@lwfinger.net> [b43, rtl8187, rtlwifi]
Acked-by: Luciano Coelho <coelho@ti.com> [wl12xx]
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7bb45683
  9. 22 2月, 2011 2 次提交
  11. 20 1月, 2011 1 次提交
    • J
      mac80211: track receiver's aggregation reorder buffer size · 0b01f030
      由 Johannes Berg 提交于 
      The aggregation code currently doesn't implement the
buffer size negotiation. It will always request a max
buffer size (which is fine, if a little pointless, as
the mac80211 code doesn't know and might just use 0
instead), but if the peer requests a smaller size it
isn't possible to honour this request.

In order to fix this, look at the buffer size in the
addBA response frame, keep track of it and pass it to
the driver in the ampdu_action callback when called
with the IEEE80211_AMPDU_TX_OPERATIONAL action. That
way the driver can limit the number of subframes in
aggregates appropriately.

Note that this doesn't fix any drivers apart from the
addition of the new argument -- they all need to be
updated separately to use this variable!
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0b01f030
  13. 17 12月, 2010 1 次提交
  15. 16 12月, 2010 1 次提交