1. 25 Feb, 2014 1 commit
  2. 24 Feb, 2014 4 commits
  3. 23 Feb, 2014 1 commit
  4. 20 Feb, 2014 13 commits
    • Sujith Manoharan's avatar
      ath9k: Fix ETSI compliance for AR9462 2.0 · b3050248
      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: default avatarJeang Daniel <dyjeong@qca.qualcomm.com>
      Signed-off-by: default avatarSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b3050248
    • Arend van Spriel's avatar
      brcmfmac: fix txglomming scatter-gather packet transfers · 1eb43018
      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: default avatarDaniel (Deognyoun) Kim <dekim@broadcom.com>
      Reviewed-by: default avatarHante Meuleman <meuleman@broadcom.com>
      Reviewed-by: default avatarFranky (Zhenhui) Lin <frankyl@broadcom.com>
      Reviewed-by: default avatarPieter-Paul Giesberts <pieterpg@broadcom.com>
      Signed-off-by: default avatarArend van Spriel <arend@broadcom.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      1eb43018
    • Stanislaw Gruszka's avatar
      ath9k: protect tid->sched check · 21f8aaee
      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: default avatarMax Sydorenko <maxim.stargazer@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      21f8aaee
    • Amitkumar Karwar's avatar
      mwifiex: fix cmd and Tx data timeout issue for PCIe cards · 1c97560f
      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: default avatarAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: default avatarBing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      1c97560f
    • Amitkumar Karwar's avatar
      mwifiex: add NULL check for PCIe Rx skb · bb8e6a1e
      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: default avatarAmitkumar Karwar <akarwar@marvell.com>
      Signed-off-by: default avatarBing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      bb8e6a1e
    • Avinash Patil's avatar
      mwifiex: clean pcie ring only when device is present · 4f7ba432
      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: default avatarAvinash Patil <patila@marvell.com>
      Signed-off-by: default avatarBing Zhao <bzhao@marvell.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4f7ba432
    • James Cameron's avatar
      libertas: fix scan result loss if SSID IE len 0 · 95320774
      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: default avatarJames Cameron <quozl@laptop.org>
      Reported-by: default avatarT Gillett <tgillett@gmail.com>
      Tested-by: default avatarT Gillett <tgillett@gmail.com>
      CC: Dan Williams <dcbw@redhat.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      95320774
    • Kirill Tkhai's avatar
      hostap: Do not free priv until timer handler has actually stopped using it · 72471c0d
      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: default avatarKirill Tkhai <ktkhai@parallels.com>
      CC: Jouni Malinen <j@w1.fi>
      CC: John W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      72471c0d
    • John W. Linville's avatar
    • Emmanuel Grumbach's avatar
      iwlwifi: dvm: clear IWL_STA_UCODE_INPROGRESS when assoc fails · ec6f678c
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      ec6f678c
    • Johannes Berg's avatar
      mac80211: fix station wakeup powersave race · e3685e03
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      e3685e03
    • Johannes Berg's avatar
      mac80211: insert stations before adding to driver · 5108ca82
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      5108ca82
    • Emmanuel Grumbach's avatar
      mac80211: fix AP powersave TX vs. wakeup race · 1d147bfa
      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: default avatarYaara Rozenblum <yaara.rozenblum@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Reviewed-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      [reword commit log, use a separate lock]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      1d147bfa
  5. 19 Feb, 2014 1 commit
  6. 13 Feb, 2014 7 commits
    • Russell King - ARM Linux's avatar
      hostap: fix "hostap: proc: Use remove_proc_subtree()" · 4885c873
      Russell King - ARM Linux authored
      remove_proc_subtree() doesn't work here as local->ddev has already
      been removed, and NULLed out.  Use proc_remove() instead.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Tested-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4885c873
    • Stanislaw Gruszka's avatar
      rtl8187: fix regression on MIPS without coherent DMA · b6213e41
      Stanislaw Gruszka authored
      This patch fixes regression caused by commit a16dad77 "MIPS: Fix
      potencial corruption". That commit fixes one corruption scenario in
      cost of adding another one, which actually start to cause crashes
      on Yeeloong laptop when rtl8187 driver is used.
      
      For correct DMA read operation on machines without DMA coherence, kernel
      have to invalidate cache, such it will refill later with new data that
      device wrote to memory, when that data is needed to process. We can only
      invalidate full cache line. Hence when cache line includes both dma
      buffer and some other data (written in cache, but not yet in main
      memory), the other data can not hit memory due to invalidation. That
      happen on rtl8187 where struct rtl8187_priv fields are located just
      before and after small buffers that are passed to USB layer and DMA
      is performed on them.
      
      To fix the problem we align buffers and reserve space after them to make
      them match cache line.
      
      This patch does not resolve all possible MIPS problems entirely, for
      that we have to assure that we always map cache aligned buffers for DMA,
      what can be complex or even not possible. But patch fixes visible and
      reproducible regression and seems other possible corruptions do not
      happen in practice, since Yeeloong laptop works stable without rtl8187
      driver.
      
      Bug report:
      https://bugzilla.kernel.org/show_bug.cgi?id=54391Reported-by: default avatarPetr Pisar <petr.pisar@atlas.cz>
      Bisected-by: default avatarTom Li <biergaizi2009@gmail.com>
      Reported-and-tested-by: default avatarTom Li <biergaizi2009@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarStanislaw Gruszka <stf_xl@wp.pl>
      Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.next>
      Acked-by: default avatarHin-Tak Leung <htl10@users.sourceforge.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      b6213e41
    • Dan Carpenter's avatar
      ath5k: shifting the wrong variable for AR5K_AR5210 · 4a0732d1
      Dan Carpenter authored
      In the original code we shift "AR5K_PHY(256) >> 28" which is zero but
      the intent was to shift the return value of ath5k_hw_reg_read() like we
      do a couple lines later.
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4a0732d1
    • Olivier Langlois's avatar
      rtlwifi: Fix incorrect return from rtl_ps_enable_nic() · 2e8c5e56
      Olivier Langlois authored
      rtl_ps_enable_nic() is called from loops that will loop until this function returns true or a
      maximum number of retries is performed.
      
      hw_init() returns non-zero on error. In that situation return false to
      restore the original design intent to retry hw init when it fails.
      Signed-off-by: default avatarOlivier Langlois <olivier@trillion01.com>
      Cc: Stable <stable@vger.kernel.org>
      Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2e8c5e56
    • Olivier Langlois's avatar
      rtlwifi: rtl8192ce: Fix too long disable of IRQs · f78bccd7
      Olivier Langlois authored
      rtl8192ce is disabling for too long the local interrupts during hw initiatialisation when performing scans
      
      The observable symptoms in dmesg can be:
      
      - underruns from ALSA playback
      - clock freezes (tstamps do not change for several dmesg entries until irqs are finaly reenabled):
      
      [  250.817669] rtlwifi:rtl_op_config():<0-0-0> 0x100
      [  250.817685] rtl8192ce:_rtl92ce_phy_set_rf_power_state():<0-1-0> IPS Set eRf nic enable
      [  250.817732] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.817796] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.817910] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818024] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818139] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818253] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818367] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:18051d59:11
      [  250.818472] rtl8192ce:_rtl92ce_init_mac():<0-1-0> reg0xec:98053f15:10
      [  250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
      [  250.818472] rtl8192c_common:rtl92c_download_fw():<0-1-0> Firmware Version(49), Signature(0x88c1),Size(32)
      [  250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> PairwiseEncAlgorithm = 0 GroupEncAlgorithm = 0
      [  250.818472] rtl8192ce:rtl92ce_enable_hw_security_config():<0-1-0> The SECR-value cc
      [  250.818472] rtl8192c_common:rtl92c_dm_check_txpower_tracking_thermal_meter():<0-1-0> Schedule TxPowerTracking direct call!!
      [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> rtl92c_dm_txpower_tracking_callback_thermalmeter
      [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf
      [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial pathA ele_d reg0xc80 = 0x40000000, ofdm_index=0xc
      [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Initial reg0xa24 = 0x90e1317, cck_index=0xc, ch14 0
      [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> Readback Thermal Meter = 0xe pre thermal meter 0xf eeprom_thermalmeter 0xf delta 0x1 delta_lck 0x0 delta_iqk 0x0
      [  250.818472] rtl8192c_common:rtl92c_dm_txpower_tracking_callback_thermalmeter():<0-1-0> <===
      [  250.818472] rtl8192c_common:rtl92c_dm_initialize_txpower_tracking_thermalmeter():<0-1-0> pMgntInfo->txpower_tracking = 1
      [  250.818472] rtl8192ce:rtl92ce_led_control():<0-1-0> ledaction 3
      [  250.818472] rtl8192ce:rtl92ce_sw_led_on():<0-1-0> LedAddr:4E ledpin=1
      [  250.818472] rtlwifi:rtl_ips_nic_on():<0-1-0> before spin_unlock_irqrestore
      [  251.154656] PCM: Lost interrupts? [Q]-0 (stream=0, delta=15903, new_hw_ptr=293408, old_hw_ptr=277505)
      
      The exact code flow that causes that is:
      
      1. wpa_supplicant send a start_scan request to the nl80211 driver
      2. mac80211 module call rtl_op_config with IEEE80211_CONF_CHANGE_IDLE
      3.   rtl_ips_nic_on is called which disable local irqs
      4.     rtl92c_phy_set_rf_power_state() is called
      5.       rtl_ps_enable_nic() is called and hw_init()is executed and then the interrupts on the device are enabled
      
      A good solution could be to refactor the code to avoid calling rtl92ce_hw_init() with the irqs disabled
      but a quick and dirty solution that has proven to work is
      to reenable the irqs during the function rtl92ce_hw_init().
      
      I think that it is safe doing so since the device interrupt will only be enabled after the init function succeed.
      Signed-off-by: default avatarOlivier Langlois <olivier@trillion01.com>
      Cc: Stable <stable@vger.kernel.org>
      Acked-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f78bccd7
    • John W. Linville's avatar
    • Emmanuel Grumbach's avatar
      iwlwifi: disable TX AMPDU by default for iwldvm · 205e2210
      Emmanuel Grumbach authored
      NICs supported by iwldvm don't handle well TX AMPDU.
      Disable it by default, still leave the possibility to
      the user to force enable it with a debug parameter.
      
      NICs supported by iwlmvm don't suffer from the same issue,
      leave TX AMPDU enabled by default for these.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      205e2210
  7. 12 Feb, 2014 1 commit
  8. 11 Feb, 2014 2 commits
  9. 06 Feb, 2014 10 commits
    • andrea.merello's avatar
      rtl8180: Add error check for pci_map_single return value in TX path · 348f7d4a
      andrea.merello authored
      Orignal code will not detect a DMA mapping failure, causing the HW
      to attempt a DMA from an invalid address.
      
      This patch add the error check and eventually simply drops the TX
      packet if we can't map it for DMA.
      Signed-off-by: default avatarandrea merello <andrea.merello@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      348f7d4a
    • andrea.merello's avatar
      rtl8180: Add error check for pci_map_single return value in RX path · 2b4db05e
      andrea.merello authored
      In original code the old RX DMA buffer is unmapped and processed and at the end
      of the isr a new buffer is mapped with pci_map_single and attached to the RX
      descriptor.
      
      If pci_map_single fails then the RX descriptor remains with no valid DMA buffer
      attached.
      In this condition the DMA will target where it shouldn't with obvious evil
      consequences.
      
      Simply avoiding re-arming the descriptor will prevent buggy DMA but it will
      result soon in RX stuck.
      
      This patch move the DMA mapping of the new buffer at the beginning of the ISR
      (and it adds error check for pci_map_single success/fail).
      
      If the DMA mapping fails then we do not unmap the old buffer and we re-arm the
      descriptor without processing it, with the old DMA buffer still attached.
      
      In this way we lose the currently RX-ed packet, but whenever next calls to
      pci_map_single will succeed again,then the RX process will go on without stuck.
      Signed-off-by: default avatarandrea merello <andrea.merello@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2b4db05e
    • John W. Linville's avatar
    • Johannes Berg's avatar
      mac80211: fix virtual monitor interface iteration · fab57a6c
      Johannes Berg authored
      During channel context assignment, the interface should
      be found by interface iteration, so we need to assign the
      pointer before the channel context.
      Reported-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Tested-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fab57a6c
    • Johannes Berg's avatar
      mac80211: fix fragmentation code, particularly for encryption · 338f977f
      Johannes Berg authored
      The "new" fragmentation code (since my rewrite almost 5 years ago)
      erroneously sets skb->len rather than using skb_trim() to adjust
      the length of the first fragment after copying out all the others.
      This leaves the skb tail pointer pointing to after where the data
      originally ended, and thus causes the encryption MIC to be written
      at that point, rather than where it belongs: immediately after the
      data.
      
      The impact of this is that if software encryption is done, then
       a) encryption doesn't work for the first fragment, the connection
          becomes unusable as the first fragment will never be properly
          verified at the receiver, the MIC is practically guaranteed to
          be wrong
       b) we leak up to 8 bytes of plaintext (!) of the packet out into
          the air
      
      This is only mitigated by the fact that many devices are capable
      of doing encryption in hardware, in which case this can't happen
      as the tail pointer is irrelevant in that case. Additionally,
      fragmentation is not used very frequently and would normally have
      to be configured manually.
      
      Fix this by using skb_trim() properly.
      
      Cc: stable@vger.kernel.org
      Fixes: 2de8e0d9 ("mac80211: rewrite fragmentation")
      Reported-by: default avatarJouni Malinen <j@w1.fi>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      338f977f
    • Sujith Manoharan's avatar
      mac80211: Fix IBSS disconnect · d4c80d9d
      Sujith Manoharan authored
      Currently, when a station leaves an IBSS network, the
      corresponding BSS is not dropped from cfg80211 if there are
      other active stations in the network. But, the small
      window that is present when trying to determine a station's
      status based on IEEE80211_IBSS_MERGE_INTERVAL introduces
      a race.
      
      Instead of trying to keep the BSS, always remove it when
      leaving an IBSS network. There is not much benefit to retain
      the BSS entry since it will be added with a subsequent join
      operation.
      
      This fixes an issue where a dangling BSS entry causes ath9k
      to wait for a beacon indefinitely.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: default avatarSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      d4c80d9d
    • Emmanuel Grumbach's avatar
      mac80211: release the channel in error path in start_ap · 0297ea17
      Emmanuel Grumbach authored
      When the driver cannot start the AP or when the assignement
      of the beacon goes wrong, we need to unassign the vif.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      0297ea17
    • Johannes Berg's avatar
      cfg80211: send scan results from work queue · f9d15d16
      Johannes Berg authored
      Due to the previous commit, when a scan finishes, it is in theory
      possible to hit the following sequence:
       1. interface starts being removed
       2. scan is cancelled by driver and cfg80211 is notified
       3. scan done work is scheduled
       4. interface is removed completely, rdev->scan_req is freed,
          event sent to userspace but scan done work remains pending
       5. new scan is requested on another virtual interface
       6. scan done work runs, freeing the still-running scan
      
      To fix this situation, hang on to the scan done message and block
      new scans while that is the case, and only send the message from
      the work function, regardless of whether the scan_req is already
      freed from interface removal. This makes step 5 above impossible
      and changes step 6 to be
       5. scan done work runs, sending the scan done message
      
      As this can't work for wext, so we send the message immediately,
      but this shouldn't be an issue since we still return -EBUSY.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f9d15d16
    • Johannes Berg's avatar
      cfg80211: fix scan done race · a617302c
      Johannes Berg authored
      When an interface/wdev is removed, any ongoing scan should be
      cancelled by the driver. This will make it call cfg80211, which
      only queues a work struct. If interface/wdev removal is quick
      enough, this can leave the scan request pending and processed
      only after the interface is gone, causing a use-after-free.
      
      Fix this by making sure the scan request is not pending after
      the interface is destroyed. We can't flush or cancel the work
      item due to locking concerns, but when it'll run it shouldn't
      find anything to do. This leaves a potential issue, if a new
      scan gets requested before the work runs, it prematurely stops
      the running scan, potentially causing another crash. I'll fix
      that in the next patch.
      
      This was particularly observed with P2P_DEVICE wdevs, likely
      because freeing them is quicker than freeing netdevs.
      Reported-by: default avatarAndrei Otcheretianski <andrei.otcheretianski@intel.com>
      Fixes: 4a58e7c3 ("cfg80211: don't "leak" uncompleted scans")
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      a617302c
    • Emmanuel Grumbach's avatar
      mac80211: avoid deadlock revealed by lockdep · 8ffcc704
      Emmanuel Grumbach authored
      sdata->u.ap.request_smps_work can’t be flushed synchronously
      under wdev_lock(wdev) since ieee80211_request_smps_ap_work
      itself locks the same lock.
      While at it, reset the driver_smps_mode when the ap is
      stopped to its default: OFF.
      
      This solves:
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.12.0-ipeer+ #2 Tainted: G           O
      -------------------------------------------------------
      rmmod/2867 is trying to acquire lock:
        ((&sdata->u.ap.request_smps_work)){+.+...}, at: [<c105b8d0>] flush_work+0x0/0x90
      
      but task is already holding lock:
        (&wdev->mtx){+.+.+.}, at: [<f9b32626>] cfg80211_stop_ap+0x26/0x230 [cfg80211]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&wdev->mtx){+.+.+.}:
              [<c10aefa9>] lock_acquire+0x79/0xe0
              [<c1607a1a>] mutex_lock_nested+0x4a/0x360
              [<fb06288b>] ieee80211_request_smps_ap_work+0x2b/0x50 [mac80211]
              [<c105cdd8>] process_one_work+0x198/0x450
              [<c105d469>] worker_thread+0xf9/0x320
              [<c10669ff>] kthread+0x9f/0xb0
              [<c1613397>] ret_from_kernel_thread+0x1b/0x28
      
      -> #0 ((&sdata->u.ap.request_smps_work)){+.+...}:
              [<c10ae9df>] __lock_acquire+0x183f/0x1910
              [<c10aefa9>] lock_acquire+0x79/0xe0
              [<c105b917>] flush_work+0x47/0x90
              [<c105d867>] __cancel_work_timer+0x67/0xe0
              [<c105d90f>] cancel_work_sync+0xf/0x20
              [<fb0765cc>] ieee80211_stop_ap+0x8c/0x340 [mac80211]
              [<f9b3268c>] cfg80211_stop_ap+0x8c/0x230 [cfg80211]
              [<f9b0d8f9>] cfg80211_leave+0x79/0x100 [cfg80211]
              [<f9b0da72>] cfg80211_netdev_notifier_call+0xf2/0x4f0 [cfg80211]
              [<c160f2c9>] notifier_call_chain+0x59/0x130
              [<c106c6de>] __raw_notifier_call_chain+0x1e/0x30
              [<c106c70f>] raw_notifier_call_chain+0x1f/0x30
              [<c14f8213>] call_netdevice_notifiers_info+0x33/0x70
              [<c14f8263>] call_netdevice_notifiers+0x13/0x20
              [<c14f82a4>] __dev_close_many+0x34/0xb0
              [<c14f83fe>] dev_close_many+0x6e/0xc0
              [<c14f9c77>] rollback_registered_many+0xa7/0x1f0
              [<c14f9dd4>] unregister_netdevice_many+0x14/0x60
              [<fb06f4d9>] ieee80211_remove_interfaces+0xe9/0x170 [mac80211]
              [<fb055116>] ieee80211_unregister_hw+0x56/0x110 [mac80211]
              [<fa3e9396>] iwl_op_mode_mvm_stop+0x26/0xe0 [iwlmvm]
              [<f9b9d8ca>] _iwl_op_mode_stop+0x3a/0x70 [iwlwifi]
              [<f9b9d96f>] iwl_opmode_deregister+0x6f/0x90 [iwlwifi]
              [<fa405179>] __exit_compat+0xd/0x19 [iwlmvm]
              [<c10b8bf9>] SyS_delete_module+0x179/0x2b0
              [<c1613421>] sysenter_do_call+0x12/0x32
      
      Fixes: 687da132 ("mac80211: implement SMPS for AP")
      Cc: <stable@vger.kernel.org> [3.13]
      Reported-by: default avatarIlan Peer <ilan.peer@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8ffcc704