1. 14 1月, 2015 1 次提交
  2. 28 11月, 2014 1 次提交
    • F
      mac80211: copy chandef from AP vif to VLANs · 2967e031
      Felix Fietkau 提交于
      Instead of keeping track of all those special cases where
      VLAN interfaces have no bss_conf.chandef, just make sure
      they have the same as the AP interface they belong to.
      
      Among others, this fixes a crash getting a VLAN's channel
      from userspace since a NULL channel is returned as a good
      result (return value 0) for VLANs since the commit below.
      
      Cc: stable@vger.kernel.org [3.18 only]
      Fixes: c12bc488 ("mac80211: return the vif's chandef in ieee80211_cfg_get_channel()")
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      [rewrite commit log]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      2967e031
  3. 20 11月, 2014 1 次提交
  4. 04 11月, 2014 2 次提交
    • R
      mac80211: 802.11p OCB mode support · 239281f8
      Rostislav Lisovy 提交于
      This patch adds 802.11p OCB (Outside the Context of a BSS) mode
      support.
      
      When communicating in OCB mode a mandatory wildcard BSSID
      (48 '1' bits) is used.
      
      The EDCA parameters handling function was changed to support
      802.11p specific values.
      
      The insertion of a newly discovered STAs is done in the similar way
      as in the IBSS mode -- through the deferred insertion.
      
      The OCB mode uses a periodic 'housekeeping task' for expiration of
      disconnected STAs (in the similar manner as in the MESH mode).
      
      New Kconfig option for verbose OCB debugging outputs is added.
      Signed-off-by: NRostislav Lisovy <rostislav.lisovy@fel.cvut.cz>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      239281f8
    • R
      cfg80211: 802.11p OCB mode handling · 6e0bd6c3
      Rostislav Lisovy 提交于
      This patch adds new iface type (NL80211_IFTYPE_OCB) representing
      the OCB (Outside the Context of a BSS) mode.
      When establishing a connection to the network a cfg80211_join_ocb
      function is called (particular nl80211_command is added as well).
      A mandatory parameters during the ocb_join operation are 'center
      frequency' and 'channel width (5/10 MHz)'.
      
      Changes done in mac80211 are minimal possible required to avoid
      many warnings (warning: enumeration value 'NL80211_IFTYPE_OCB'
      not handled in switch) during compilation. Full functionality
      (where needed) is added in the following patch.
      Signed-off-by: NRostislav Lisovy <rostislav.lisovy@fel.cvut.cz>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6e0bd6c3
  5. 30 10月, 2014 1 次提交
  6. 29 10月, 2014 1 次提交
  7. 27 10月, 2014 1 次提交
  8. 09 10月, 2014 1 次提交
  9. 05 9月, 2014 1 次提交
  10. 03 9月, 2014 1 次提交
    • M
      mac80211: fix offloaded BA session traffic after hw restart · 4549cf2b
      Michal Kazior 提交于
      When starting an offloaded BA session it is
      unknown what starting sequence number should be
      used. Using last_seq worked in most cases except
      after hw restart.
      
      When hw restart is requested last_seq is
      (rightfully so) kept unmodified. This ended up
      with BA sessions being restarted with an aribtrary
      BA window values resulting in dropped frames until
      sequence numbers caught up.
      
      Instead of last_seq pick seqno of a first Rxed
      frame of a given BA session.
      
      This fixes stalled traffic after hw restart with
      offloaded BA sessions (currently only ath10k).
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      4549cf2b
  11. 26 8月, 2014 1 次提交
  12. 21 7月, 2014 2 次提交
  13. 16 7月, 2014 1 次提交
    • T
      net: set name_assign_type in alloc_netdev() · c835a677
      Tom Gundersen 提交于
      Extend alloc_netdev{,_mq{,s}}() to take name_assign_type as argument, and convert
      all users to pass NET_NAME_UNKNOWN.
      
      Coccinelle patch:
      
      @@
      expression sizeof_priv, name, setup, txqs, rxqs, count;
      @@
      
      (
      -alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs)
      +alloc_netdev_mqs(sizeof_priv, name, NET_NAME_UNKNOWN, setup, txqs, rxqs)
      |
      -alloc_netdev_mq(sizeof_priv, name, setup, count)
      +alloc_netdev_mq(sizeof_priv, name, NET_NAME_UNKNOWN, setup, count)
      |
      -alloc_netdev(sizeof_priv, name, setup)
      +alloc_netdev(sizeof_priv, name, NET_NAME_UNKNOWN, setup)
      )
      
      v9: move comments here from the wrong commit
      Signed-off-by: NTom Gundersen <teg@jklm.no>
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c835a677
  14. 23 6月, 2014 4 次提交
  15. 09 6月, 2014 1 次提交
  16. 28 5月, 2014 1 次提交
  17. 26 5月, 2014 1 次提交
    • E
      mac80211: fix virtual monitor interface addition · 34171dc0
      Emmanuel Grumbach 提交于
      Since the commit below, cfg80211_chandef_dfs_required()
      will warn if it gets a an NL80211_IFTYPE_UNSPECIFIED iftype
      as explicitely written in the commit log.
      When an virtual monitor interface is added, its type is set
      in ieee80211_sub_if_data.vif.type, but not in
      ieee80211_sub_if_data.wdev.iftype which is passed to
      cfg80211_chandef_dfs_required() hence resulting in the
      following warning:
      
      WARNING: CPU: 1 PID: 21265 at net/wireless/chan.c:376 cfg80211_chandef_dfs_required+0xbc/0x130 [cfg80211]()
      Modules linked in: [...]
      CPU: 1 PID: 21265 Comm: ifconfig Tainted: G        W  O 3.13.11+ #12
      Hardware name: Dell Inc. Latitude E6410/0667CC, BIOS A01 03/05/2010
       0000000000000009 ffff88008f5fdb08 ffffffff817d4219 ffff88008f5fdb50
       ffff88008f5fdb40 ffffffff8106f57d 0000000000000000 0000000000000000
       ffff880081062fb8 ffff8800810604e0 0000000000000001 ffff88008f5fdba0
      Call Trace:
       [<ffffffff817d4219>] dump_stack+0x4d/0x66
       [<ffffffff8106f57d>] warn_slowpath_common+0x7d/0xa0
       [<ffffffff8106f5ec>] warn_slowpath_fmt+0x4c/0x50
       [<ffffffffa04ea4ec>] cfg80211_chandef_dfs_required+0xbc/0x130 [cfg80211]
       [<ffffffffa06b1024>] ieee80211_vif_use_channel+0x94/0x500 [mac80211]
       [<ffffffffa0684e6b>] ieee80211_add_virtual_monitor+0x1ab/0x5c0 [mac80211]
       [<ffffffffa0686ae5>] ieee80211_do_open+0xe75/0x1580 [mac80211]
       [<ffffffffa0687259>] ieee80211_open+0x69/0x70 [mac80211]
      [snip]
      
      Fixes: 00ec75fc ("cfg80211: pass the actual iftype when calling cfg80211_chandef_dfs_required()")
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Acked-by: NLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      34171dc0
  18. 06 5月, 2014 1 次提交
    • M
      mac80211: fix CSA tx queue stopping · 59af6928
      Michal Kazior 提交于
      It was possible for tx queues to be stuck stopped
      if AP CSA finalization failed. In that case
      neither stop_ap nor do_stop woke the queues up.
      This means it was impossible to perform tx at all
      until driver was reloaded or a successful CSA was
      performed later.
      
      It was possible to solve this in a simpler manner
      however this is more robust and future proof
      (having multi-vif CSA in mind).
      
      New sdata->csa_block_tx is introduced to keep
      track of which interfaces requested tx to be
      blocked for CSA. This is required because mac80211
      stops all tx queues for that purpose. This means
      queues must be awoken only when last tx-blocking
      CSA interface is finished.
      
      It is still possible to have tx queues stopped
      after CSA failure but as soon as offending
      interfaces are stopped from userspace (stop_ap or
      ifdown) tx queues are woken up properly.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      59af6928
  19. 25 4月, 2014 3 次提交
  20. 09 4月, 2014 3 次提交
  21. 17 2月, 2014 1 次提交
  22. 12 2月, 2014 1 次提交
  23. 06 2月, 2014 2 次提交
    • 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
    • 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
  24. 05 2月, 2014 1 次提交
  25. 11 1月, 2014 1 次提交
    • J
      net: core: explicitly select a txq before doing l2 forwarding · f663dd9a
      Jason Wang 提交于
      Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit(). The
      will cause several issues:
      
      - NETIF_F_LLTX were removed for macvlan, so txq lock were done for macvlan
        instead of lower device which misses the necessary txq synchronization for
        lower device such as txq stopping or frozen required by dev watchdog or
        control path.
      - dev_hard_start_xmit() was called with NULL txq which bypasses the net device
        watchdog.
      - dev_hard_start_xmit() does not check txq everywhere which will lead a crash
        when tso is disabled for lower device.
      
      Fix this by explicitly introducing a new param for .ndo_select_queue() for just
      selecting queues in the case of l2 forwarding offload. netdev_pick_tx() was also
      extended to accept this parameter and dev_queue_xmit_accel() was used to do l2
      forwarding transmission.
      
      With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's no need
      to check txq against NULL in dev_hard_start_xmit(). Also there's no need to keep
      a dedicated ndo_dfwd_start_xmit() and we can just reuse the code of
      dev_queue_xmit() to do the transmission.
      
      In the future, it was also required for macvtap l2 forwarding support since it
      provides a necessary synchronization method.
      
      Cc: John Fastabend <john.r.fastabend@intel.com>
      Cc: Neil Horman <nhorman@tuxdriver.com>
      Cc: e1000-devel@lists.sourceforge.net
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f663dd9a
  26. 27 12月, 2013 1 次提交
  27. 19 12月, 2013 2 次提交
    • J
      mac80211: fix iflist_mtx/mtx locking in radar detection · 34a3740d
      Johannes Berg 提交于
      The scan code creates an iflist_mtx -> mtx locking dependency,
      and a few other places, notably radar detection, were creating
      the opposite dependency, causing lockdep to complain. As scan
      and radar detection are mutually exclusive, the deadlock can't
      really happen in practice, but it's still bad form.
      
      A similar issue exists in the monitor mode code, but this is
      only used by channel-context drivers right now and those have
      to have hardware scan, so that also can't happen.
      
      Still, fix these issues by making some of the channel context
      code require the mtx to be held rather than acquiring it, thus
      allowing the monitor/radar callers to keep the iflist_mtx->mtx
      lock ordering.
      
      While at it, also fix access to the local->scanning variable
      in the radar code, and document that radar_detect_enabled is
      now properly protected by the mtx.
      
      All this would now introduce an ABBA deadlock between the DFS
      work cancelling and local->mtx, so change the locking there a
      bit to not need to use cancel_delayed_work_sync() but be able
      to just use cancel_delayed_work(). The work is also safely
      stopped/removed when the interface is stopped, so no extra
      changes are needed.
      Reported-by: NKalle Valo <kvalo@qca.qualcomm.com>
      Tested-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      34a3740d
    • J
      mac80211: remove unnecessary iflist_mtx locking · 6924d013
      Johannes Berg 提交于
      The radar detection code changed a few times, and due to
      the changes some iflist_mtx locking stayed in that isn't
      actually necessary - remove it.
      
      One version of the code needed it because an AP interface's
      VLAN list was changed to use this, but then we moved the
      list handling outside of the chanctx handling and thus the
      locking was no longer needed.
      Tested-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6924d013
  28. 16 12月, 2013 2 次提交
    • J
      mac80211: free all AP/VLAN keys at once · 7907c7d3
      Johannes Berg 提交于
      When the AP interface is stopped, free all AP and VLAN keys at
      once to only require synchronize_net() once. Since that does
      synchronize_net(), also move two such calls into the function
      (using the new force_synchronize parameter) to avoid doing it
      twice.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      7907c7d3
    • J
      mac80211: don't delay station destruction · d34ba216
      Johannes Berg 提交于
      If we can assume that stations are never referenced by the
      driver after sta_state returns (and this is true since the
      previous iwlmvm patch and for all other drivers) then we
      don't need to delay station destruction, and don't need to
      play tricks with rcu_barrier() etc.
      
      This should speed up some scenarios like hostapd shutdown.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d34ba216