- 16 2月, 2012 3 次提交
-
-
由 Amitkumar Karwar 提交于
Driver maintains different flags for WEP, WPA, WPA2 security modes. Appropriate flag is set using security information provided in connect request. mwifiex_is_network_compatible() routine uses them to check if driver's setting is compatible with AP. Association is aborted if the routine fails. For some corner cases, it is observed that association is failed even for valid security information based on association history. This patch fixes the problem by clearing previous security setting during each association. We should set WEP key provided in connect request as default tx key. This missing change is also added here. Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
Most rate control implementations assume .get_rate and .tx_status are only called once the per-station data has been fully initialized. minstrel_ht crashes if this assumption is violated. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Tested-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
There are situations where we don't have the necessary rate control information yet for station entries, e.g. when associating. This currently doesn't really happen due to the dummy station handling; explicitly disabling rate control when it's not initialised will allow us to remove dummy stations. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 15 2月, 2012 13 次提交
-
-
由 Ulisses Furquim 提交于
We need to use the _sync() version for cancelling the info and security timer in the L2CAP connection delete path. Otherwise the delayed work handler might run after the connection object is freed. Signed-off-by: NUlisses Furquim <ulisses@profusion.mobi> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Ulisses Furquim 提交于
__cancel_delayed_work() is being used in some paths where we cannot sleep waiting for the delayed work to finish. However, that function might return while the timer is running and the work will be queued again. Replace the calls with safer cancel_delayed_work() version which spins until the timer handler finishes on other CPUs and cancels the delayed work. Signed-off-by: NUlisses Furquim <ulisses@profusion.mobi> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Manoj Iyer 提交于
T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0a5c ProdID=21f3 Rev=01.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=74DE2B344A7B C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Signed-off-by: NManoj Iyer <manoj.iyer@canonical.com> Tested-by: NDennis Chua <dennis.chua@canonical.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Johan Hedberg 提交于
We should only perform a reset in hci_dev_do_close if the HCI_QUIRK_NO_RESET flag is set (since in such a case a reset will not be performed when initializing the device). Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Octavian Purdila 提交于
There is an imbalance in the rfcomm_session_hold / rfcomm_session_put operations which causes the following crash: [ 685.010159] BUG: unable to handle kernel paging request at 6b6b6b6b [ 685.010169] IP: [<c149d76d>] rfcomm_process_dlcs+0x1b/0x15e [ 685.010181] *pdpt = 000000002d665001 *pde = 0000000000000000 [ 685.010191] Oops: 0000 [#1] PREEMPT SMP [ 685.010247] [ 685.010255] Pid: 947, comm: krfcommd Tainted: G C 3.0.16-mid8-dirty #44 [ 685.010266] EIP: 0060:[<c149d76d>] EFLAGS: 00010246 CPU: 1 [ 685.010274] EIP is at rfcomm_process_dlcs+0x1b/0x15e [ 685.010281] EAX: e79f551c EBX: 6b6b6b6b ECX: 00000007 EDX: e79f40b4 [ 685.010288] ESI: e79f4060 EDI: ed4e1f70 EBP: ed4e1f68 ESP: ed4e1f50 [ 685.010295] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 685.010303] Process krfcommd (pid: 947, ti=ed4e0000 task=ed43e5e0 task.ti=ed4e0000) [ 685.010308] Stack: [ 685.010312] ed4e1f68 c149eb53 e5925150 e79f4060 ed500000 ed4e1f70 ed4e1f80 c149ec10 [ 685.010331] 00000000 ed43e5e0 00000000 ed4e1f90 ed4e1f9c c149ec87 0000bf54 00000000 [ 685.010348] 00000000 ee03bf54 c149ec37 ed4e1fe4 c104fe01 00000000 00000000 00000000 [ 685.010367] Call Trace: [ 685.010376] [<c149eb53>] ? rfcomm_process_rx+0x6e/0x74 [ 685.010387] [<c149ec10>] rfcomm_process_sessions+0xb7/0xde [ 685.010398] [<c149ec87>] rfcomm_run+0x50/0x6d [ 685.010409] [<c149ec37>] ? rfcomm_process_sessions+0xde/0xde [ 685.010419] [<c104fe01>] kthread+0x63/0x68 [ 685.010431] [<c104fd9e>] ? __init_kthread_worker+0x42/0x42 [ 685.010442] [<c14dae82>] kernel_thread_helper+0x6/0xd This issue has been brought up earlier here: https://lkml.org/lkml/2011/5/21/127 The issue appears to be the rfcomm_session_put in rfcomm_recv_ua. This operation doesn't seem be to required as for the non-initiator case we have the rfcomm_process_rx doing an explicit put and in the initiator case the last dlc_unlink will drive the reference counter to 0. There have been several attempts to fix these issue: 6c2718da Bluetooth: Do not call rfcomm_session_put() for RFCOMM UA on closed socket 683d949a Bluetooth: Never deallocate a session when some DLC points to it but AFAICS they do not fix the issue just make it harder to reproduce. Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com> Signed-off-by: NGopala Krishna Murala <gopala.krishna.murala@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Andre Guedes 提交于
We don't need to use the _sync variant in hci_conn_hold and hci_conn_put to cancel conn->disc_work delayed work. This way we avoid potential deadlocks like this one reported by lockdep. ====================================================== [ INFO: possible circular locking dependency detected ] 3.2.0+ #1 Not tainted ------------------------------------------------------- kworker/u:1/17 is trying to acquire lock: (&hdev->lock){+.+.+.}, at: [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth] but task is already holding lock: ((&(&conn->disc_work)->work)){+.+...}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 ((&(&conn->disc_work)->work)){+.+...}: [<ffffffff81057444>] lock_acquire+0x8a/0xa7 [<ffffffff81034ed1>] wait_on_work+0x3d/0xaa [<ffffffff81035b54>] __cancel_work_timer+0xac/0xef [<ffffffff81035ba4>] cancel_delayed_work_sync+0xd/0xf [<ffffffffa00554b0>] smp_chan_create+0xde/0xe6 [bluetooth] [<ffffffffa0056160>] smp_conn_security+0xa3/0x12d [bluetooth] [<ffffffffa0053640>] l2cap_connect_cfm+0x237/0x2e8 [bluetooth] [<ffffffffa004239c>] hci_proto_connect_cfm+0x2d/0x6f [bluetooth] [<ffffffffa0046ea5>] hci_event_packet+0x29d1/0x2d60 [bluetooth] [<ffffffffa003dde3>] hci_rx_work+0xd0/0x2e1 [bluetooth] [<ffffffff810357af>] process_one_work+0x178/0x2bf [<ffffffff81036178>] worker_thread+0xce/0x152 [<ffffffff81039a03>] kthread+0x95/0x9d [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10 -> #1 (slock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}: [<ffffffff81057444>] lock_acquire+0x8a/0xa7 [<ffffffff812e553a>] _raw_spin_lock_bh+0x36/0x6a [<ffffffff81244d56>] lock_sock_nested+0x24/0x7f [<ffffffffa004d96f>] lock_sock+0xb/0xd [bluetooth] [<ffffffffa0052906>] l2cap_chan_connect+0xa9/0x26f [bluetooth] [<ffffffffa00545f8>] l2cap_sock_connect+0xb3/0xff [bluetooth] [<ffffffff81243b48>] sys_connect+0x69/0x8a [<ffffffff812e6579>] system_call_fastpath+0x16/0x1b -> #0 (&hdev->lock){+.+.+.}: [<ffffffff81056d06>] __lock_acquire+0xa80/0xd74 [<ffffffff81057444>] lock_acquire+0x8a/0xa7 [<ffffffff812e3870>] __mutex_lock_common+0x48/0x38e [<ffffffff812e3c75>] mutex_lock_nested+0x2a/0x31 [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth] [<ffffffff810357af>] process_one_work+0x178/0x2bf [<ffffffff81036178>] worker_thread+0xce/0x152 [<ffffffff81039a03>] kthread+0x95/0x9d [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10 other info that might help us debug this: Chain exists of: &hdev->lock --> slock-AF_BLUETOOTH-BTPROTO_L2CAP --> (&(&conn->disc_work)->work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((&(&conn->disc_work)->work)); lock(slock-AF_BLUETOOTH-BTPROTO_L2CAP); lock((&(&conn->disc_work)->work)); lock(&hdev->lock); *** DEADLOCK *** 2 locks held by kworker/u:1/17: #0: (hdev->name){.+.+.+}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf #1: ((&(&conn->disc_work)->work)){+.+...}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf stack backtrace: Pid: 17, comm: kworker/u:1 Not tainted 3.2.0+ #1 Call Trace: [<ffffffff812e06c6>] print_circular_bug+0x1f8/0x209 [<ffffffff81056d06>] __lock_acquire+0xa80/0xd74 [<ffffffff81021ef2>] ? arch_local_irq_restore+0x6/0xd [<ffffffff81022bc7>] ? vprintk+0x3f9/0x41e [<ffffffff81057444>] lock_acquire+0x8a/0xa7 [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth] [<ffffffff812e3870>] __mutex_lock_common+0x48/0x38e [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth] [<ffffffff81190fd6>] ? __dynamic_pr_debug+0x6d/0x6f [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth] [<ffffffff8105320f>] ? trace_hardirqs_off+0xd/0xf [<ffffffff812e3c75>] mutex_lock_nested+0x2a/0x31 [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth] [<ffffffff810357af>] process_one_work+0x178/0x2bf [<ffffffff81035751>] ? process_one_work+0x11a/0x2bf [<ffffffff81055af3>] ? lock_acquired+0x1d0/0x1df [<ffffffffa00410f3>] ? hci_acl_disconn+0x65/0x65 [bluetooth] [<ffffffff81036178>] worker_thread+0xce/0x152 [<ffffffff810407ed>] ? finish_task_switch+0x45/0xc5 [<ffffffff810360aa>] ? manage_workers.isra.25+0x16a/0x16a [<ffffffff81039a03>] kthread+0x95/0x9d [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10 [<ffffffff812e5db4>] ? retint_restore_args+0x13/0x13 [<ffffffff8103996e>] ? __init_kthread_worker+0x55/0x55 [<ffffffff812e7750>] ? gs_change+0x13/0x13 Signed-off-by: NAndre Guedes <andre.guedes@openbossa.org> Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Reviewed-by: NUlisses Furquim <ulisses@profusion.mobi> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Octavian Purdila 提交于
Since bluetooth uses multiple protocols types, to avoid lockdep warnings, we need to use different lockdep classes (one for each protocol type). This is already done in bt_sock_create but it misses a couple of cases when new connections are created. This patch corrects that to fix the following warning: <4>[ 1864.732366] ======================================================= <4>[ 1864.733030] [ INFO: possible circular locking dependency detected ] <4>[ 1864.733544] 3.0.16-mid3-00007-gc9a0f62 #3 <4>[ 1864.733883] ------------------------------------------------------- <4>[ 1864.734408] t.android.btclc/4204 is trying to acquire lock: <4>[ 1864.734869] (rfcomm_mutex){+.+.+.}, at: [<c14970ea>] rfcomm_dlc_close+0x15/0x30 <4>[ 1864.735541] <4>[ 1864.735549] but task is already holding lock: <4>[ 1864.736045] (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c1498bf7>] lock_sock+0xa/0xc <4>[ 1864.736732] <4>[ 1864.736740] which lock already depends on the new lock. <4>[ 1864.736750] <4>[ 1864.737428] <4>[ 1864.737437] the existing dependency chain (in reverse order) is: <4>[ 1864.738016] <4>[ 1864.738023] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}: <4>[ 1864.738549] [<c1062273>] lock_acquire+0x104/0x140 <4>[ 1864.738977] [<c13d35c1>] lock_sock_nested+0x58/0x68 <4>[ 1864.739411] [<c1493c33>] l2cap_sock_sendmsg+0x3e/0x76 <4>[ 1864.739858] [<c13d06c3>] __sock_sendmsg+0x50/0x59 <4>[ 1864.740279] [<c13d0ea2>] sock_sendmsg+0x94/0xa8 <4>[ 1864.740687] [<c13d0ede>] kernel_sendmsg+0x28/0x37 <4>[ 1864.741106] [<c14969ca>] rfcomm_send_frame+0x30/0x38 <4>[ 1864.741542] [<c1496a2a>] rfcomm_send_ua+0x58/0x5a <4>[ 1864.741959] [<c1498447>] rfcomm_run+0x441/0xb52 <4>[ 1864.742365] [<c104f095>] kthread+0x63/0x68 <4>[ 1864.742742] [<c14d5182>] kernel_thread_helper+0x6/0xd <4>[ 1864.743187] <4>[ 1864.743193] -> #0 (rfcomm_mutex){+.+.+.}: <4>[ 1864.743667] [<c1061ada>] __lock_acquire+0x988/0xc00 <4>[ 1864.744100] [<c1062273>] lock_acquire+0x104/0x140 <4>[ 1864.744519] [<c14d2c70>] __mutex_lock_common+0x3b/0x33f <4>[ 1864.744975] [<c14d303e>] mutex_lock_nested+0x2d/0x36 <4>[ 1864.745412] [<c14970ea>] rfcomm_dlc_close+0x15/0x30 <4>[ 1864.745842] [<c14990d9>] __rfcomm_sock_close+0x5f/0x6b <4>[ 1864.746288] [<c1499114>] rfcomm_sock_shutdown+0x2f/0x62 <4>[ 1864.746737] [<c13d275d>] sys_socketcall+0x1db/0x422 <4>[ 1864.747165] [<c14d42f0>] syscall_call+0x7/0xb Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Vinicius Costa Gomes 提交于
queue_delayed_work() expects a relative time for when that work should be scheduled. Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@openbossa.org> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Andrzej Kaczmarek 提交于
After moving L2CAP timers to workqueues l2cap_set_timer expects timeout value to be specified in jiffies but constants defined in miliseconds are used. This makes timeouts unreliable when CONFIG_HZ is not set to 1000. __set_chan_timer macro still uses jiffies as input to avoid multiple conversions from/to jiffies for sk_sndtimeo value which is already specified in jiffies. Signed-off-by: NAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Ackec-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Andrzej Kaczmarek 提交于
sk_sndtime value should be specified in jiffies thus initial value needs to be converted from miliseconds. Otherwise this timeout is unreliable when CONFIG_HZ is not set to 1000. Signed-off-by: NAndrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Johan Hedberg 提交于
As reported by Dan Carpenter this function causes a Sparse warning and shouldn't be declared inline: include/net/bluetooth/l2cap.h:837:30 error: marked inline, but without a definition" Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org>
-
由 Daniel Wagner 提交于
[ 2096.384084] btusb_send_frame:684: hci0 [ 2096.384087] usb 3-1: BOGUS urb flags, 2 --> 0 [ 2096.384091] Bluetooth: hci0 urb ffff8801b61d3a80 submission failed (22) According the documentation in usb_submit_urb() URB_ISO_ASAP flag is only allowed for endpoints of type USB_ENDPOINT_XFER_ISOC. This reverts commit b8aabfc9. Signed-off-by: NDaniel Wagner <daniel.wagner@bmw-carit.de> Acked-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
由 Peter Hurley 提交于
Commit 33060542 fixed l2cap conn establishment for non-ssp remote devices by not setting HCI_CONN_ENCRYPT_PEND every time conn security is tested (which was always returning failure on any subsequent security checks). However, this broke l2cap conn establishment for ssp remote devices when an ACL link was already established at SDP-level security. This fix ensures that encryption must be pending whenever authentication is also pending. Signed-off-by: NPeter Hurley <peter@hurleysoftware.com> Tested-by: NDaniel Wagner <daniel.wagner@bmw-carit.de> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
-
- 10 2月, 2012 2 次提交
-
-
由 Simon Graham 提交于
Fixes problem where caller would think routine succeeded when it failed leading to divide by zero panic. Signed-off-by: NSimon Graham <simon.graham@virtualcomputer.com> Acked-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Mohammed Shafi Shajakhan 提交于
read_lock(&tpt_trig->trig.leddev_list_lock) is accessed via the path ieee80211_open (->) ieee80211_do_open (->) ieee80211_mod_tpt_led_trig (->) ieee80211_start_tpt_led_trig (->) tpt_trig_timer before initializing it. the intilization of this read/write lock happens via the path ieee80211_led_init (->) led_trigger_register, but we are doing 'ieee80211_led_init' after 'ieeee80211_if_add' where we register netdev_ops. so we access leddev_list_lock before initializing it and causes the following bug in chrome laptops with AR928X cards with the following script while true do sudo modprobe -v ath9k sleep 3 sudo modprobe -r ath9k sleep 3 done BUG: rwlock bad magic on CPU#1, wpa_supplicant/358, f5b9eccc Pid: 358, comm: wpa_supplicant Not tainted 3.0.13 #1 Call Trace: [<8137b9df>] rwlock_bug+0x3d/0x47 [<81179830>] do_raw_read_lock+0x19/0x29 [<8137f063>] _raw_read_lock+0xd/0xf [<f9081957>] tpt_trig_timer+0xc3/0x145 [mac80211] [<f9081f3a>] ieee80211_mod_tpt_led_trig+0x152/0x174 [mac80211] [<f9076a3f>] ieee80211_do_open+0x11e/0x42e [mac80211] [<f9075390>] ? ieee80211_check_concurrent_iface+0x26/0x13c [mac80211] [<f9076d97>] ieee80211_open+0x48/0x4c [mac80211] [<812dbed8>] __dev_open+0x82/0xab [<812dc0c9>] __dev_change_flags+0x9c/0x113 [<812dc1ae>] dev_change_flags+0x18/0x44 [<8132144f>] devinet_ioctl+0x243/0x51a [<81321ba9>] inet_ioctl+0x93/0xac [<812cc951>] sock_ioctl+0x1c6/0x1ea [<812cc78b>] ? might_fault+0x20/0x20 [<810b1ebb>] do_vfs_ioctl+0x46e/0x4a2 [<810a6ebb>] ? fget_light+0x2f/0x70 [<812ce549>] ? sys_recvmsg+0x3e/0x48 [<810b1f35>] sys_ioctl+0x46/0x69 [<8137fa77>] sysenter_do_call+0x12/0x2 Cc: <stable@vger.kernel.org> Cc: Gary Morain <gmorain@google.com> Cc: Paul Stewart <pstew@google.com> Cc: Abhijit Pradhan <abhijit@qca.qualcomm.com> Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com> Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Acked-by: NJohannes Berg <johannes.berg@intel.com> Tested-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 08 2月, 2012 1 次提交
-
-
由 Tomas Vanek 提交于
Some devices (iwl5100) cannot connect to zd1211rw based AP. It appears that zd1211 firmware messes up duration_id field if it is not set to zero by driver. Sniffing traffic shows that zd1211 is transmitting frames with duration_id bits 14 and 15 set and other bits appearing random. Setting duration_id at driver to zero results zd1211 outputting sane duration_id. This means that firmware is setting correct values itself and expects duration_id to be zero in first place. Looking at vendor driver shows that only PSPoll frames have duration_id set by driver, for other frames duration_id left zero. Original bug-report and attached patch at: http://sourceforge.net/mailarchive/message.php?msg_id=28759111Reported-by: NTomas Vanek <Tomas.Vanek@fbl.cz> [modified original patch from bug-report, added check for pspoll frame] Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 07 2月, 2012 4 次提交
-
-
由 Henrik Rydberg 提交于
The brcmsmac driver is now using the bcma SPROM CRC check, which does not recognize all chipsets that were functional prior to the switch. In particular, the current code bails out on odd CRC errors in recent Macbooks. This patch ignores those errors, with the argument that an unrecognized SPROM should be treated similarly to a non-existing one. Signed-off-by: NHenrik Rydberg <rydberg@euromail.se> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
commit adb5066a "ath9k_hw: do not apply the 2.4 ghz ack timeout workaround to cts" reduced the hardware CTS timeout to the normal values specified by the standard, but it turns out while it doesn't need the same extra time that it needs for the ACK timeout, it does need more than the value specified in the standard, but only for 2.4 GHz. This patch brings the CTS timeout value in sync with the initialization values, while still allowing adjustment for bigger distances. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Cc: stable@vger.kernel.org Reported-by: NSeth Forshee <seth.forshee@canonical.com> Reported-by: NMarek Lindner <lindner_marek@yahoo.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Felix Fietkau 提交于
commit b4a82a0 "ath9k_hw: fix interpretation of the rx KeyMiss flag" fixed the interpretation of the KeyMiss flag for keycache based lookups, however WEP encryption uses a static index, so KeyMiss is always asserted for it, even though frames are decrypted properly. Fix this by clearing the ATH9K_RXERR_KEYMISS flag if no keycache based lookup was performed. Signed-off-by: NFelix Fietkau <nbd@openwrt.org> Cc: stable@vger.kernel.org Reported-by: NLaurent Bonnans <bonnans.l@gmail.com> Reported-by: NJurica Vukadin <u.ra604@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Amitkumar Karwar 提交于
If driver load is failed, sometimes few pointers may remain uninitialized ex. priv->wdev, priv->netdev, adapter->sleep_cfm This will cause NULL pointer dereferance while unloading the driver. Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NKiran Divekar <dkiran@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 04 2月, 2012 3 次提交
-
-
由 Mohammed Shafi Shajakhan 提交于
all works need to be initialized before ieee80211_register_hw to prevent mac80211 call backs such as drv_start, drv_config getting started. otherwise we would queue/cancel works before initializing them and it leads to kernel panic. this issue can be recreated with the following script in Chrome laptops with AR928X cards, with background scan running (or) Network manager is running while true do sudo modprobe -v ath9k sleep 3 sudo modprobe -r ath9k sleep 3 done EIP: [<81040a47>] __cancel_work_timer+0xb8/0xe1 SS:ESP 0068:f6be9d70 ---[ end trace 4f86d6139a9900ef ]--- Registered led device: ath9k-phy0 ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf88a0000, irq=16 Kernel panic - not syncing: Fatal exception Pid: 456, comm: wpa_supplicant Tainted: G D 3.0.13 #1 Call Trace: [<81379e21>] panic+0x53/0x14a [<81004a30>] oops_end+0x73/0x81 [<81004b53>] die+0x4c/0x55 [<81002710>] do_trap+0x7c/0x83 [<81002855>] ? do_bounds+0x58/0x58 [<810028cc>] do_invalid_op+0x77/0x81 [<81040a47>] ? __cancel_work_timer+0xb8/0xe1 [<810489ec>] ? sched_clock_cpu+0x81/0x11f [<8103f809>] ? wait_on_work+0xe2/0xf7 [<8137f807>] error_code+0x67/0x6c [<810300d8>] ? wait_consider_task+0x4ba/0x84c [<81040a47>] ? __cancel_work_timer+0xb8/0xe1 [<810380c9>] ? try_to_del_timer_sync+0x5f/0x67 [<81040a91>] cancel_work_sync+0xf/0x11 [<f88d7b7c>] ath_set_channel+0x62/0x25c [ath9k] [<f88d67d1>] ? ath9k_tx_last_beacon+0x26a/0x85c [ath9k] [<f88d8899>] ath_radio_disable+0x3f1/0x68e [ath9k] [<f90d0edb>] ieee80211_hw_config+0x111/0x116 [mac80211] [<f90dd95c>] __ieee80211_recalc_idle+0x919/0xa37 [mac80211] [<f90dda76>] __ieee80211_recalc_idle+0xa33/0xa37 [mac80211] [<812dbed8>] __dev_open+0x82/0xab Cc: <stable@vger.kernel.org> Cc: Gary Morain <gmorain@google.com> Cc: Paul Stewart <pstew@google.com> Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com> Tested-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Amitkumar Karwar 提交于
Currently even if association is failed "iw link" shows some information about connected BSS and "Tx timeout" error is seen in dmesg log. This patch fixes below issues in the code to handle assoc failure case correctly. 1) "status" variable in mwifiex_wait_queue_complete() is not correctly updated. Hence driver doesn't inform cfg80211 stack about association failure. 2) During association network queues are stopped but carrier is not cleared, which gives Tx timeout error in failure case Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 John W. Linville 提交于
The device seems to survive the issue, so no need to flood the logs about it... Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 02 2月, 2012 6 次提交
-
-
由 Eliad Peller 提交于
The current code checks for stored_mpdu_num > 1, causing the reorder_timer to be triggered indefinitely, but the frame is never timed-out (until the next packet is received) Signed-off-by: NEliad Peller <eliad@wizery.com> Cc: <stable@vger.kernel.org> Acked-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Emmanuel Grumbach 提交于
In my AMPDU rework, I rely on the sequence numbers of frames. But I didn't check that the frame has a valid tid before updating the tracking counters. As a result, the Tx queues were stalled. People who hit this bug saw that we simply didn't let any data out. This bug was introduced in 3.3. This patch fixes that and checks that the frame is a QoS frame before looking at its tid and changing the counters. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Hauke Mehrtens 提交于
ssb supports one extra device on the cardbus. This results in two devices in total, one beeing the host controller itself and the other the external device connected to the hostcontroller over cardbus. This makes the cardbus slot work on the Linksys WRT150N. Reported-by: NAaron Z <aaronz@pls-net.org> Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 John W. Linville 提交于
Average users either don't care or they think that message indicates a problem... Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Luigi Tarenga 提交于
This patch correct the type of variables containing the rssi values read from the rxwi. In function rt2800_agc_to_rssi() 3 variables (rssi0, rssi1, rss2) defined as int was assigned a 16bit signed values as unsigned. From a test with a hi-gain antenna I verified that the rxwi contains signed rssi values in the range -13/+81 (inclusive) with 0 as an error condition. In case of negative values a condition is triggered and the function return -128dBm while the signal is at its maximum. This patch correct the cast so negative values are not treated as very high positive values (ex. -13 does not become 243). Signed-off-by: NLuigi Tarenga <luigi.tarenga@gmail.com> Reviewed-by: NStanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Jesper Juhl 提交于
bcma_bus_scan() leaks 'struct bcma_device' bytes if bcma_get_next_core() returns error. Restructure the code so we always kfree() the memory we allocate to the variable 'core' before it goes out of scope. Signed-off-by: NJesper Juhl <jj@chaosbits.net> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 31 1月, 2012 3 次提交
-
-
由 Eric Dumazet 提交于
Commit 0884d7aa (AF_UNIX: Fix poll blocking problem when reading from a stream socket) added a regression for epoll() in Edge Triggered mode (EPOLLET) Appropriate fix is to use skb_peek()/skb_unlink() instead of skb_dequeue(), and only call skb_unlink() when skb is fully consumed. This remove the need to requeue a partial skb into sk_receive_queue head and the extra sk->sk_data_ready() calls that added the regression. This is safe because once skb is given to sk_receive_queue, it is not modified by a writer, and readers are serialized by u->readlock mutex. This also reduce number of spinlock acquisition for small reads or MSG_PEEK users so should improve overall performance. Reported-by: NNick Mathewson <nickm@freehaven.net> Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com> Cc: Alexey Moiseytsev <himeraster@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Neal Cardwell 提交于
This commit fixes tcp_trim_head() to recalculate the number of segments in the skb with the skb's existing MSS, so trimming the head causes the skb segment count to be monotonically non-increasing - it should stay the same or go down, but not increase. Previously tcp_trim_head() used the current MSS of the connection. But if there was a decrease in MSS between original transmission and ACK (e.g. due to PMTUD), this could cause tcp_trim_head() to counter-intuitively increase the segment count when trimming bytes off the head of an skb. This violated assumptions in tcp_tso_acked() that tcp_trim_head() only decreases the packet count, so that packets_acked in tcp_tso_acked() could underflow, leading tcp_clean_rtx_queue() to pass u32 pkts_acked values as large as 0xffffffff to ca_ops->pkts_acked(). As an aside, if tcp_trim_head() had really wanted the skb to reflect the current MSS, it should have called tcp_set_skb_tso_segs() unconditionally, since a decrease in MSS would mean that a single-packet skb should now be sliced into multiple segments. Signed-off-by: NNeal Cardwell <ncardwell@google.com> Acked-by: NNandita Dukkipati <nanditad@google.com> Acked-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Glauber Costa 提交于
sysctl_tcp_mem() initialization was moved to sysctl_tcp_ipv4.c in commit 3dc43e3e, since it became a per-ns value. That code, however, will never run when CONFIG_SYSCTL is disabled, leading to bogus values on those fields - causing hung TCP sockets. This patch fixes it by keeping an initialization code in tcp_init(). It will be overwritten by the first net namespace init if CONFIG_SYSCTL is compiled in, and do the right thing if it is compiled out. It is also named properly as tcp_init_mem(), to properly signal its non-sysctl side effect on TCP limits. Reported-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NGlauber Costa <glommer@parallels.com> Cc: David S. Miller <davem@davemloft.net> Link: http://lkml.kernel.org/r/4F22D05A.8030604@parallels.com [ renamed the function, tidied up the changelog a bit ] Signed-off-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 28 1月, 2012 3 次提交
-
-
由 Eric W. Biederman 提交于
caif is a subsystem and as such it needs to register with register_pernet_subsys instead of register_pernet_device. Among other problems using register_pernet_device was resulting in net_generic being called before the caif_net structure was allocated. Which has been causing net_generic to fail with either BUG_ON's or by return NULL pointers. A more ugly problem that could be caused is packets in flight why the subsystem is shutting down. To remove confusion also remove the cruft cause by inappropriately trying to fix this bug. With the aid of the previous patch I have tested this patch and confirmed that using register_pernet_subsys makes the failure go away as it should. Signed-off-by: NEric W. Biederman <ebiederm@xmission.com> Acked-by: NSjur Brændeland <sjur.brandeland@stericsson.com> Tested-by: NSasha Levin <levinsasha928@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Eric W. Biederman 提交于
By definition net_generic should never be called when it can return NULL. Fail conspicously with a BUG_ON to make it clear when people mess up that a NULL return should never happen. Recently there was a bug in the CAIF subsystem where it was registered with register_pernet_device instead of register_pernet_subsys. It was erroneously concluded that net_generic could validly return NULL and that net_assign_generic was buggy (when it was just inefficient). Hopefully this BUG_ON will prevent people to coming to similar erroneous conclusions in the futrue. Signed-off-by: NEric W. Biederman <ebiederm@xmission.com> Tested-by: NSasha Levin <levinsasha928@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 27 1月, 2012 2 次提交
-
-
由 Glauber Costa 提交于
Commit 36a12119 removed linux/module.h include statement from one of the headers that end up in net/sock.h. It was providing us with static_branch() definition implicitly, so after its removal the build got broken. To fix this, and avoid having this happening in the future, let me do the right thing and include linux/jump_label.h explicitly in sock.h. Signed-off-by: NGlauber Costa <glommer@parallels.com> Reported-by: NRandy Dunlap <rdunlap@xenotime.net> CC: David S. Miller <davem@davemloft.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Stefan Gula 提交于
Setting link parameters on a netdevice changes the value of if_nlmsg_size(), therefore it is necessary to recalculate min_ifinfo_dump_size. Signed-off-by: NStefan Gula <steweg@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-