- 13 Mar, 2014 2 commits
-
-
Felix Fietkau authored
The commit "ath9k: reduce baseband hang detection false positive rate" added a delay in the loop checking the baseband state, however it was unreachable due to previous 'continue' statements. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Dave Jones authored
Commit 1eb43018 (brcmfmac: fix txglomming scatter-gather packet transfers) added an allocation of an skb via brcmu_pkt_buf_get_skb() but forgot to free it on one of the error paths. Acked-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by: Dave Jones<davej@fedoraproject.org> Signed-off-by:
-
- 06 Mar, 2014 3 commits
-
-
Amitkumar Karwar authored
While preparing association request, intersection of device's VHT capability information and corresponding field advertised by AP is used. This patch fixes a couple errors while saving and copying vht_cap and vht_oper fields from AP's beacon. Cc: <stable@vger.kernel.org> # 3.9+ Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Amitkumar Karwar authored
While preparing association request, intersection of device's HT capability information and corresponding fields advertised by AP is used. This patch fixes an error while copying this field from AP's beacon. Cc: <stable@vger.kernel.org> Signed-off-by:
-
-
- 05 Mar, 2014 1 commit
-
-
Johannes Berg authored
Avoid leaking data by sending uninitialized memory and setting an invalid (non-zero) fragment number (the sequence number is ignored anyway) by setting the seq_ctrl field to zero. Cc: stable@vger.kernel.org Fixes: 3f52b7e3 ("mac80211: mesh power save basics") Fixes: ce662b44 ("mac80211: send (QoS) Null if no buffered frames") Reviewed-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- 04 Mar, 2014 4 commits
-
-
-
Ivaylo Dimitrov authored
the current code is directly setting skb->len, which is not correct and brings problems with HAVE_EFFICIENT_UNALIGNED_ACCESS enabled in config Signed-off-by:
Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Signed-off-by:
-
Oren Givon authored
Update of the HW IDs for the 7265 series. Signed-off-by:
Oren Givon <oren.givon@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
Since the statistics handler is asynchrous, it can very well be that we will handle the statistics (hence the RSSI fluctuation) when we already disassociated. Don't WARN on this case. This solves: https://bugzilla.redhat.com/show_bug.cgi?id=1071998 Cc: <stable@vger.kernel.org> [3.10+] Fixes: 2b76ef13 ("iwlwifi: mvm: implement reduced Tx power") Reviewed-by:
-
- 03 Mar, 2014 2 commits
-
-
Johannes Berg authored
In case of AP mode, the beacon interval is already reset to zero inside cfg80211_stop_ap(), and in the other modes it isn't relevant. Remove the assignment to remove a potential race since the assignment isn't properly locked. Reported-by:
Michal Kazior <michal.kazior@tieto.com> Signed-off-by:
-
Eliad Peller authored
When calculating the current max bw required for a channel context, we didn't consider the virtual monitor interface, resulting in its channel context being narrower than configured. This broke monitor mode with iwlmvm, which uses the minimal width. Reported-by:
Ido Yariv <idox.yariv@intel.com> Signed-off-by:
Eliad Peller <eliadx.peller@intel.com> Signed-off-by:
-
- 28 Feb, 2014 3 commits
-
-
Bing Zhao authored
As many Surface Pro I & II users have found out, the mwifiex_usb doesn't support usb autosuspend, and it has caused some system stability issues. Bug 69661 - mwifiex_usb on MS Surface Pro 1 is unstable Bug 60815 - Interface hangs in mwifiex_usb Bug 64111 - mwifiex_usb USB8797 crash failed to get signal information USB autosuspend get triggered when Surface Pro's AC power is removed or powertop enables power saving on USB8797 device. Driver's suspend handler is called here, but resume handler won't be called until the AC power is put back on or powertop disables power saving for USB8797. We need to refactor the suspend/resume handlers to support usb autosuspend properly. For now let's just remove it. Cc: <stable@vger.kernel.org> # 3.5+ Signed-off-by:
-
-
-
- 27 Feb, 2014 3 commits
-
-
Johannes Berg authored
When a VHT network uses 20 or 40 MHz as per the HT operation information, the channel center frequency segment 0 field in the VHT operation information is reserved, so ignore it. This fixes association with such networks when the AP puts 0 into the field, previously we'd disconnect due to an invalid channel with the message wlan0: AP VHT information is invalid, disable VHT Cc: stable@vger.kernel.org Fixes: f2d9d270 ("mac80211: support VHT association") Reported-by:
Tim Nelson <tim.l.nelson@gmail.com> Signed-off-by:
-
Johannes Berg authored
Only the first packet is currently handled correctly, but then all others are assumed to have failed which is problematic. Fix this, marking them all successful instead (since if they're not then the firmware will have transmitted them as single frames.) This fixes the lost packet reporting. Also do a tiny variable scoping cleanup. Cc: <stable@vger.kernel.org> Signed-off-by:
-
Max Stepanov authored
Some APs reject STA association request if a listen interval value exceeds a threshold of 10. Thus, for example, Cisco APs may deny STA associations returning status code 12 (Association denied due to reason outside the scope of 802.11 standard) in the association response frame. Fixing the issue by setting the default IWL_CONN_MAX_LISTEN_INTERVAL value from 70 to 10. Cc: <stable@vger.kernel.org> [3.10+] Signed-off-by:
Max Stepanov <Max.Stepanov@intel.com> Reviewed-by:
Alexander Bondar <alexander.bondar@intel.com> Signed-off-by:
-
- 25 Feb, 2014 3 commits
-
-
Felix Fietkau authored
Only set sc->rx.discard_next to rx_stats->rs_more when actually discarding the current descriptor. Also, fix a detection of broken descriptors: First the code checks if the current descriptor is not done. Then it checks if the next descriptor is done. Add a check that afterwards checks the first descriptor again, because it might have been completed in the mean time. This fixes a regression introduced in commit 723e7113 "ath9k: fix handling of broken descriptors" Cc: stable@vger.kernel.org Reported-by:
Marco André Dinis <marcoandredinis@gmail.com> Signed-off-by:
-
Felix Fietkau authored
Check if the baseband state remains stable, and add a small delay between register reads. Signed-off-by:
-
Janusz Dziedzic authored
Reset regdomain to world regdomain in case of errors in set_regdom() function. This will fix a problem with such scenario: - iw reg set US - iw reg set 00 - iw reg set US The last step always fail and we get deadlock in kernel regulatory code. Next setting new regulatory wasn't possible due to: Pending regulatory request, waiting for it to be processed... Signed-off-by:
Janusz Dziedzic <janusz.dziedzic@tieto.com> Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
-
- 24 Feb, 2014 5 commits
-
-
Felix Fietkau authored
When passing tx frames to the U-APSD queue for powersave poll responses, the ath_atx_tid pointer needs to be passed to ath_tx_setup_buffer for proper sequence number accounting. This fixes high latency and connection stability issues with ath9k running as AP and a few kinds of mobile phones as client, when PS-Poll is heavily used Cc: stable@vger.kernel.org Signed-off-by:
-
Bing Zhao authored
Both libertas USB driver and mwifiex_usb driver are registerring with name 'usb8xxx'. The following conflict happens while trying to load both drivers. [6.211307] Error: Driver 'usb8xxx' is already registered... [6.217261] mwifiex_usb: Driver register failed! Fix it by renaming mwifiex_usb driver's name. Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixesJohn W. Linville authored
Samuel Ortiz <sameo@linux.intel.com> says: "NFC: 3.14: First pull request We only have one candidate for 3.14 fixes, and this is a NCI NULL pointer dereference introduced during the 3.14 merge window." Signed-off-by: -
-
Johannes Berg authored
The MLME code in mac80211 must track whether or not the AP changed bandwidth, but if there's no change while tracking it shouldn't do anything, otherwise regulatory updates can make it impossible to connect to certain APs if the regulatory database doesn't match the information from the AP. See the precise scenario described in the code. This still leaves some possible problems with CSA or if the AP actually changed bandwidth, but those cases are less common and won't completely prevent using it. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=70881 Cc: stable@vger.kernel.org Reported-and-tested-by:
Nate Carlson <kernel@natecarlson.com> Signed-off-by:
-
- 23 Feb, 2014 1 commit
-
-
Amitkumar Karwar authored
The check should be for setup function pointer. This patch fixes NULL pointer dereference issue for NCI based NFC driver which doesn't define setup handler. Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
- 20 Feb, 2014 13 commits
-
-
Sujith Manoharan authored
The minimum CCA power threshold values have to be adjusted for existing cards to be in compliance with new regulations. Newer cards will make use of the values obtained from EEPROM, support for this was added earlier. To make sure that cards that are already in use and don't have proper values in EEPROM, do not violate regulations, use the initvals instead. Cc: stable@vger.kernel.org Reported-by:
Jeang Daniel <dyjeong@qca.qualcomm.com> Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
-
Arend van Spriel authored
The driver concatenates multiple packets in one MMC transfer. For scatter-gather to work the total length need to be multiple of 512 bytes. A pre-allocated buffer was used to add padding to accomplish that. However, the length was not properly set and it was freed after the first transfer causing a crash. Reviewed-by:
Daniel (Deognyoun) Kim <dekim@broadcom.com> Reviewed-by:
Hante Meuleman <meuleman@broadcom.com> Reviewed-by:
Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by:
-
Stanislaw Gruszka authored
We check tid->sched without a lock taken on ath_tx_aggr_sleep(). That is race condition which can result of doing list_del(&tid->list) twice (second time with poisoned list node) and cause crash like shown below: [424271.637220] BUG: unable to handle kernel paging request at 00100104 [424271.637328] IP: [<f90fc072>] ath_tx_aggr_sleep+0x62/0xe0 [ath9k] ... [424271.639953] Call Trace: [424271.639998] [<f90f6900>] ? ath9k_get_survey+0x110/0x110 [ath9k] [424271.640083] [<f90f6942>] ath9k_sta_notify+0x42/0x50 [ath9k] [424271.640177] [<f809cfef>] sta_ps_start+0x8f/0x1c0 [mac80211] [424271.640258] [<c10f730e>] ? free_compound_page+0x2e/0x40 [424271.640346] [<f809e915>] ieee80211_rx_handlers+0x9d5/0x2340 [mac80211] [424271.640437] [<c112f048>] ? kmem_cache_free+0x1d8/0x1f0 [424271.640510] [<c1345a84>] ? kfree_skbmem+0x34/0x90 [424271.640578] [<c10fc23c>] ? put_page+0x2c/0x40 [424271.640640] [<c1345a84>] ? kfree_skbmem+0x34/0x90 [424271.640706] [<c1345a84>] ? kfree_skbmem+0x34/0x90 [424271.640787] [<f809dde3>] ? ieee80211_rx_handlers_result+0x73/0x1d0 [mac80211] [424271.640897] [<f80a07a0>] ieee80211_prepare_and_rx_handle+0x520/0xad0 [mac80211] [424271.641009] [<f809e22d>] ? ieee80211_rx_handlers+0x2ed/0x2340 [mac80211] [424271.641104] [<c13846ce>] ? ip_output+0x7e/0xd0 [424271.641182] [<f80a1057>] ieee80211_rx+0x307/0x7c0 [mac80211] [424271.641266] [<f90fa6ee>] ath_rx_tasklet+0x88e/0xf70 [ath9k] [424271.641358] [<f80a0f2c>] ? ieee80211_rx+0x1dc/0x7c0 [mac80211] [424271.641445] [<f90f82db>] ath9k_tasklet+0xcb/0x130 [ath9k] Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=70551Reported-and-tested-by:
Max Sydorenko <maxim.stargazer@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Amitkumar Karwar authored
We are sending sleep confirm done interrupt in the middle of sleep handshake. There is a corner case when Tx done interrupt is received from firmware during sleep handshake due to which host and firmware power states go out of sync causing cmd and Tx data timeout problem. Hence sleep confirm done interrupt is sent at the end of sleep handshake to fix the problem. Cc: <stable@vger.kernel.org> # 3.10+ Signed-off-by:
-
Amitkumar Karwar authored
We may get a NULL pointer here if skb allocation for Rx packet was failed earlier. Cc: <stable@vger.kernel.org> # 3.9+ Signed-off-by:
-
Avinash Patil authored
Write io memory to clean PCIe buffer only when PCIe device is present else this results into crash because of invalid memory access. Cc: <stable@vger.kernel.org> # 3.9+ Signed-off-by:
Avinash Patil <patila@marvell.com> Signed-off-by:
-
James Cameron authored
Scan results from Marvell 8388 and 8686 have probe responses from hidden APs and OLPC XO-1 mesh with a zero length SSID IE. Bug in lbs_ret_scan discarded any remaining BSS in scan response, leading to user not seeing APs in dense environments. With LBS_DEB_SCAN, dmesg shows libertas scan: scan response: 5 BSSs (419 bytes); resp size 474 bytes libertas scan: scan: 00:1a:2b:84:de:e8, capa 0401, chan 1, qz, -51 dBm libertas scan: scan: 5c:63:bf:d8:eb:0c, capa 0411, chan 1, qw129, -23 dBm libertas scan: scan response: invalid IE fmt With LBS_DEB_HEX, dmesg shows valid BSS in scan response were not processed. Change is to ignore zero length IE and continue processing. Fixes OLPC 12757, http://dev.laptop.org/ticket/12757Signed-off-by:
James Cameron <quozl@laptop.org> Reported-by:
T Gillett <tgillett@gmail.com> Tested-by:
-
Kirill Tkhai authored
Function del_timer() does not guarantee that timer was really deleted. If the timer handler is beeing executed at the moment, the function does nothing. So, it's possible to use already freed memory in the handler: [ref: Documentation/DocBook/kernel-locking.tmpl] This was found using grep and compile-tested only. Please, consider applying or something similar to it. Signed-off-by:
Kirill Tkhai <ktkhai@parallels.com> CC: Jouni Malinen <j@w1.fi> CC: John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
-
Emmanuel Grumbach authored
We set IWL_STA_UCODE_INPROGRESS flag when we add a station and clear it when we send the LQ command for it. But the LQ command is sent only when the association succeeds. If the association doesn't succeed, we would leave this flag set and that wouldn't indicate the station entry as vacant. This probably fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1065663 Cc: <stable@vger.kernel.org> Reviewed-by:
-
Johannes Berg authored
Consider the following (relatively unlikely) scenario: 1) station goes to sleep while frames are buffered in driver 2) driver blocks wakeup (until no more frames are buffered) 3) station wakes up again 4) driver unblocks wakeup In this case, the current mac80211 code will do the following: 1) WLAN_STA_PS_STA set 2) WLAN_STA_PS_DRIVER set 3) - nothing - 4) WLAN_STA_PS_DRIVER cleared As a result, no frames will be delivered to the client, even though it is awake, until it sends another frame to us that triggers ieee80211_sta_ps_deliver_wakeup() in sta_ps_end(). Since we now take the PS spinlock, we can fix this while at the same time removing the complexity with the pending skb queue function. This was broken since my commit 50a9432d ("mac80211: fix powersaving clients races") due to removing the clearing of WLAN_STA_PS_STA in the RX path. While at it, fix a cleanup path issue when a station is removed while the driver is still blocking its wakeup. Signed-off-by:
-
Johannes Berg authored
There's a race condition in mac80211 because we add stations to the internal lists after adding them to the driver, which means that (for example) the following can happen: 1. a station connects and is added 2. first, it is added to the driver 3. then, it is added to the mac80211 lists If the station goes to sleep between steps 2 and 3, and the firmware/hardware records it as being asleep, mac80211 will never instruct the driver to wake it up again as it never realized it went to sleep since the RX path discarded the frame as a "spurious class 3 frame", no station entry was present yet. Fix this by adding the station in software first, and only then adding it to the driver. That way, any state that the driver changes will be reflected properly in mac80211's station state. The problematic part is the roll-back if the driver fails to add the station, in that case a bit more is needed. To not make that overly complex prevent starting BA sessions in the meantime. Signed-off-by: -
Emmanuel Grumbach authored
There is a race between the TX path and the STA wakeup: while a station is sleeping, mac80211 buffers frames until it wakes up, then the frames are transmitted. However, the RX and TX path are concurrent, so the packet indicating wakeup can be processed while a packet is being transmitted. This can lead to a situation where the buffered frames list is emptied on the one side, while a frame is being added on the other side, as the station is still seen as sleeping in the TX path. As a result, the newly added frame will not be send anytime soon. It might be sent much later (and out of order) when the station goes to sleep and wakes up the next time. Additionally, it can lead to the crash below. Fix all this by synchronising both paths with a new lock. Both path are not fastpath since they handle PS situations. In a later patch we'll remove the extra skb queue locks to reduce locking overhead. BUG: unable to handle kernel NULL pointer dereference at 000000b0 IP: [<ff6f1791>] ieee80211_report_used_skb+0x11/0x3e0 [mac80211] *pde = 00000000 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC EIP: 0060:[<ff6f1791>] EFLAGS: 00210282 CPU: 1 EIP is at ieee80211_report_used_skb+0x11/0x3e0 [mac80211] EAX: e5900da0 EBX: 00000000 ECX: 00000001 EDX: 00000000 ESI: e41d00c0 EDI: e5900da0 EBP: ebe458e4 ESP: ebe458b0 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 CR0: 8005003b CR2: 000000b0 CR3: 25a78000 CR4: 000407d0 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process iperf (pid: 3934, ti=ebe44000 task=e757c0b0 task.ti=ebe44000) iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command LQ_CMD (#4e), seq: 0x0903, 92 bytes at 3[3]:9 Stack: e403b32c ebe458c4 00200002 00200286 e403b338 ebe458cc c10960bb e5900da0 ff76a6ec ebe458d8 00000000 e41d00c0 e5900da0 ebe458f0 ff6f1b75 e403b210 ebe4598c ff723dc1 00000000 ff76a6ec e597c978 e403b758 00000002 00000002 Call Trace: [<ff6f1b75>] ieee80211_free_txskb+0x15/0x20 [mac80211] [<ff723dc1>] invoke_tx_handlers+0x1661/0x1780 [mac80211] [<ff7248a5>] ieee80211_tx+0x75/0x100 [mac80211] [<ff7249bf>] ieee80211_xmit+0x8f/0xc0 [mac80211] [<ff72550e>] ieee80211_subif_start_xmit+0x4fe/0xe20 [mac80211] [<c149ef70>] dev_hard_start_xmit+0x450/0x950 [<c14b9aa9>] sch_direct_xmit+0xa9/0x250 [<c14b9c9b>] __qdisc_run+0x4b/0x150 [<c149f732>] dev_queue_xmit+0x2c2/0xca0 Cc: stable@vger.kernel.org Reported-by:
Yaara Rozenblum <yaara.rozenblum@intel.com> Signed-off-by:
-
