1. 21 2月, 2014 4 次提交
  2. 20 2月, 2014 2 次提交
  3. 13 2月, 2014 1 次提交
    • J
      mac80211: add NAPI support back · 06d181a8
      Johannes Berg 提交于
      NAPI was originally added to mac80211 a long time ago (by John in
      commit 4e6cbfd0 in July 2010), but then removed years later
      (by Stanislaw in commit 30c97120 in February 2013). No driver
      ever used it, so that was fine.
      
      Now I'm adding support for NAPI to our driver, so add some code
      to mac80211 again  to support NAPI. John was originally wrapping
      some (but not nearly all NAPI-related functions), but that doesn't
      scale very well with the number of functions that are there, some
      of which are even only inlines. Thus, instead of doing that, let
      the drivers manage the NAPI struct, except for napi_add() which is
      needed so mac80211 knows how to call napi_gro_receive().
      
      Also remove some no longer needed definitions that were left when
      NAPI support was removed.
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Reviewed-by: NEyal Shapira <eyal@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      06d181a8
  4. 12 2月, 2014 4 次提交
  5. 11 2月, 2014 3 次提交
  6. 08 2月, 2014 3 次提交
  7. 06 2月, 2014 14 次提交
    • J
      mac80211: remove superfluous band variable · 4bf332c7
      Johannes Berg 提交于
      We already have a band variable, so the new one is just
      shadowing it, but the existing one already holds the
      same value so just remove the inner one.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      4bf332c7
    • J
      mac80211: fix virtual monitor interface iteration · fab57a6c
      Johannes Berg 提交于
      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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Tested-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      fab57a6c
    • J
      mac80211: fix fragmentation code, particularly for encryption · 338f977f
      Johannes Berg 提交于
      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: NJouni Malinen <j@w1.fi>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      338f977f
    • S
      mac80211: Fix IBSS disconnect · d4c80d9d
      Sujith Manoharan 提交于
      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: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d4c80d9d
    • E
      mac80211: release the channel in error path in start_ap · 0297ea17
      Emmanuel Grumbach 提交于
      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: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      0297ea17
    • J
      cfg80211: send scan results from work queue · f9d15d16
      Johannes Berg 提交于
      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: NJohannes Berg <johannes.berg@intel.com>
      f9d15d16
    • J
      cfg80211: fix scan done race · a617302c
      Johannes Berg 提交于
      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: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
      Fixes: 4a58e7c3 ("cfg80211: don't "leak" uncompleted scans")
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      a617302c
    • E
      mac80211: avoid deadlock revealed by lockdep · 8ffcc704
      Emmanuel Grumbach 提交于
      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: NIlan Peer <ilan.peer@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8ffcc704
    • J
      cfg80211: re-enable 5/10 MHz support · 5a6aa705
      Johannes Berg 提交于
      Unfortunately I forgot this during the merge window, but the
      patch seems small enough to go in as a fix. The userspace API
      bug that was the reason for disabling it has long been fixed.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      5a6aa705
    • P
      nl80211: Reset split_start when netlink skb is exhausted · f12cb289
      Pontus Fuchs 提交于
      When the netlink skb is exhausted split_start is left set. In the
      subsequent retry, with a larger buffer, the dump is continued from the
      failing point instead of from the beginning.
      
      This was causing my rt28xx based USB dongle to now show up when
      running "iw list" with an old iw version without split dump support.
      
      Cc: stable@vger.kernel.org
      Fixes: 3713b4e3 ("nl80211: allow splitting wiphy information in dumps")
      Signed-off-by: NPontus Fuchs <pontus.fuchs@gmail.com>
      [avoid the entire workaround when state->split is set]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f12cb289
    • E
      mac80211: move roc cookie assignment earlier · 2f617435
      Eliad Peller 提交于
      ieee80211_start_roc_work() might add a new roc
      to existing roc, and tell cfg80211 it has already
      started.
      
      However, this might happen before the roc cookie
      was set, resulting in REMAIN_ON_CHANNEL (started)
      event with null cookie. Consequently, it can make
      wpa_supplicant go out of sync.
      
      Fix it by setting the roc cookie earlier.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      2f617435
    • E
      mac80211: propagate STBC / LDPC flags to radiotap · 63c361f5
      Emmanuel Grumbach 提交于
      This capabilities weren't propagated to the radiotap header.
      We don't set here the VHT_KNOWN / MCS_HAVE flag because not
      all the low level drivers will know how to properly flag
      the frames, hence the low level driver will be in charge
      of setting IEEE80211_RADIOTAP_MCS_HAVE_FEC,
      IEEE80211_RADIOTAP_MCS_HAVE_STBC and / or
      IEEE80211_RADIOTAP_VHT_KNOWN_STBC according to its
      capabilities.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      63c361f5
    • E
      mac80211: move VHT related RX_FLAG to another variable · 1b8d242a
      Emmanuel Grumbach 提交于
      ieee80211_rx_status.flags is full. Define a new vht_flag
      variable to be able to set more VHT related flags and make
      room in flags.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Acked-by: Kalle Valo <kvalo@qca.qualcomm.com> [ath10k]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1b8d242a
    • E
      mac80211: remove unused radiotap vendor fields in ieee80211_rx_status · 0059b2b1
      Emmanuel Grumbach 提交于
      The purpose of this housekeeping is to make some room for
      VHT flags. The radiotap vendor fields weren't in use.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      0059b2b1
  8. 05 2月, 2014 9 次提交
    • J
      mac80211: order IEs in association request correctly · 3de3802c
      Johannes Berg 提交于
      In association request frames, there may be IEs passed from
      userspace (such as interworking IEs) between HT and VHT, so
      add code to insert those inbetween them.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      3de3802c
    • J
      mac80211: order IEs in probe request correctly · 4d952300
      Johannes Berg 提交于
      In probe request frames, the VHT IEs should come before any
      vendor IEs, but after interworking and similar, so add code
      to order them correctly wrt. the IEs passed from userspace.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      4d952300
    • M
      mac80211: update opmode when adding new station · b1bce14a
      Marek Kwaczynski 提交于
      Update the operating mode field is needed when an association
      request contains the operating mode notification element and
      it's not just changed later on the fly.
      Signed-off-by: NMarek Kwaczynski <marek.kwaczynski@tieto.com>
      [clarify commit log, comments & fix whitespace]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b1bce14a
    • J
      cfg80211: regulatory introduce maximum bandwidth calculation · 97524820
      Janusz Dziedzic 提交于
      In case we will get regulatory request with rule
      where max_bandwidth_khz is set to 0 handle this
      case as a special one.
      
      If max_bandwidth_khz == 0 we should calculate maximum
      available bandwidth base on all frequency contiguous rules.
      In case we need auto calculation we just have to set:
      
      country PL: DFS-ETSI
              (2402 - 2482 @ 40), (N/A, 20)
              (5170 - 5250 @ AUTO), (N/A, 20)
              (5250 - 5330 @ AUTO), (N/A, 20), DFS
              (5490 - 5710 @ 80), (N/A, 27), DFS
      
      This mean we will calculate maximum bw for rules where
      AUTO (N/A) were set, 160MHz (5330 - 5170) in example above.
      So we will get:
              (5170 - 5250 @ 160), (N/A, 20)
              (5250 - 5330 @ 160), (N/A, 20), DFS
      
      In other case:
      country FR: DFS-ETSI
              (2402 - 2482 @ 40), (N/A, 20)
              (5170 - 5250 @ AUTO), (N/A, 20)
              (5250 - 5330 @ 80), (N/A, 20), DFS
              (5490 - 5710 @ 80), (N/A, 27), DFS
      
      We will get 80MHz (5250 - 5170):
              (5170 - 5250 @ 80), (N/A, 20)
              (5250 - 5330 @ 80), (N/A, 20), DFS
      
      Base on this calculations we will set correct channel
      bandwidth flags (eg. IEEE80211_CHAN_NO_80MHZ).
      
      We don't need any changes in CRDA or internal regulatory.
      Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
      [extend nl80211 description a bit, fix typo]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      97524820
    • M
      cfg80211: consider existing DFS interfaces · 9e0e2961
      Michal Kazior 提交于
      It was possible to break interface combinations in
      the following way:
      
       combo 1: iftype = AP, num_ifaces = 2, num_chans = 2,
       combo 2: iftype = AP, num_ifaces = 1, num_chans = 1, radar = HT20
      
      With the above interface combinations it was
      possible to:
      
       step 1. start AP on DFS channel by matching combo 2
       step 2. start AP on non-DFS channel by matching combo 1
      
      This was possible beacuse (step 2) did not consider
      if other interfaces require radar detection.
      
      The patch changes how cfg80211 tracks channels -
      instead of channel itself now a complete chandef
      is stored.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      9e0e2961
    • A
      cfg80211: fix channel configuration in IBSS join · fe94f3a4
      Antonio Quartulli 提交于
      When receiving an IBSS_JOINED event select the BSS object
      based on the {bssid, channel} couple rather than the bssid
      only.
      With the current approach if another cell having the same
      BSSID (but using a different channel) exists then cfg80211
      picks up the wrong BSS object.
      The result is a mismatching channel configuration between
      cfg80211 and the driver, that can lead to any sort of
      problem.
      
      The issue can be triggered by having an IBSS sitting on
      given channel and then asking the driver to create a new
      cell using the same BSSID but with a different frequency.
      By passing the channel to cfg80211_get_bss() we can solve
      this ambiguity and retrieve/create the correct BSS object.
      All the users of cfg80211_ibss_joined() have been changed
      accordingly.
      
      Moreover WARN when cfg80211_ibss_joined() gets a NULL
      channel as argument and remove a bogus call of the same
      function in ath6kl (it does not make sense to call
      cfg80211_ibss_joined() with a zero BSSID on ibss-leave).
      
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: Arend van Spriel <arend@broadcom.com>
      Cc: Bing Zhao <bzhao@marvell.com>
      Cc: Jussi Kivilinna <jussi.kivilinna@iki.fi>
      Cc: libertas-dev@lists.infradead.org
      Acked-by: NKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
      [minor code cleanup in ath6kl]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      fe94f3a4
    • S
      net: rfkill: move poll work to power efficient workqueue · 67235cbc
      Shaibal Dutta 提交于
      This patch moves the rfkill poll_work to the power efficient workqueue.
      This work does not have to be bound to the CPU that scheduled it, hence
      the selection of CPU that executes it would be left to the scheduler.
      Net result is that CPU idle times would be extended, resulting in power
      savings.
      
      This behaviour is enabled when CONFIG_WQ_POWER_EFFICIENT is selected.
      
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NShaibal Dutta <shaibal.dutta@broadcom.com>
      [zoran.markovic@linaro.org: Rebased to latest kernel, added commit message.
      Fixed workqueue selection after suspend/resume cycle.]
      Signed-off-by: NZoran Markovic <zoran.markovic@linaro.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      67235cbc
    • S
      net: wireless: move regulatory timeout work to power efficient workqueue · 845f3351
      Shaibal Dutta 提交于
      For better use of CPU idle time, allow the scheduler to select the CPU
      on which the timeout work of regulatory settings would be executed.
      This extends CPU idle residency time and saves power.
      
      This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected.
      
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NShaibal Dutta <shaibal.dutta@broadcom.com>
      [zoran.markovic@linaro.org: Rebased to latest kernel. Added commit message.]
      Signed-off-by: NZoran Markovic <zoran.markovic@linaro.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      845f3351
    • J
      mac80211: fix bufferable MMPDU RX handling · b4ba544c
      Johannes Berg 提交于
      Action, disassoc and deauth frames are bufferable, and as such don't
      have the PM bit in the frame control field reserved which means we
      need to react to the bit when receiving in such a frame.
      
      Fix this by introducing a new helper ieee80211_is_bufferable_mmpdu()
      and using it for the RX path that currently ignores the PM bit in
      any non-data frames for doze->wake transitions, but listens to it in
      all frames for wake->doze transitions, both of which are wrong.
      
      Also use the new helper in the TX path to clean up the code.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b4ba544c
新手
引导
客服 返回
顶部