1. 06 2月, 2014 2 次提交
    • 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
    • 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
  2. 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
  3. 10 1月, 2014 4 次提交
    • J
      mac80211: handle MMPDUs at EOSP correctly · b77cf4f8
      Johannes Berg 提交于
      If a uAPSD service period ends with an MMPDU, we currently just
      send that MMPDU, but it obviously won't get the EOSP bit set as
      it doesn't have a QoS header. This contradicts the standard, so
      add a QoS-nulldata frame after the MMPDU to properly terminate
      the service period with a frame that has EOSP set.
      
      Also fix a bug wrt. the TID for the MMPDU, it shouldn't be set
      to 0 unconditionally but use the actual TID that was assigned.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b77cf4f8
    • J
      mac80211: reset TX info flags when frame will be reprocessed · 03c8c06f
      Johannes Berg 提交于
      The temporary TX info flags need to be cleared if the frame will
      be processed through the TX handlers again, otherwise it can get
      messed up. This fixes a bug that happened when an aggregation
      session was stopped while the station was sleeping - some frames
      might get transmitted marked as aggregation erroneously without
      this fix.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      03c8c06f
    • J
      mac80211: release multiple ACs in uAPSD, fix more-data bug · f9f760b4
      Johannes Berg 提交于
      When a response for PS-Poll or a uAPSD trigger frame is sent, the
      more-data bit should be set according to 802.11-2012 11.2.1.5 h),
      meaning that it should indicate more data on the relevant ACs
      (delivery-enabled or nondelivery-enabled for uAPSD or PS-Poll.)
      
      In, for example, the following scenario:
       * 1 frame on VO queue (either in driver or in mac80211)
       * at least 1 frame on VI queue (in the driver)
       * both VO/VI are delivery-enabled
       * uAPSD trigger frame received
      
      The more-data flag to the driver would not be set, even though
      it should be.
      
      While fixing this, I noticed that we should really release frames
      from multiple ACs where there's data buffered in the driver for
      the corresponding TIDs.
      
      To address all this, restructure the code a bit to consider all
      ACs if we only release driver frames or only buffered frames.
      This also addresses the more-data bug described above as now the
      TIDs will all be marked as released, so the driver will have to
      check the number of frames.
      
      While at it, clarify some code and comments and remove the found
      variable, replacing it with the appropriate sw/hw release check.
      Reported-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f9f760b4
    • J
      mac80211: fix PS-Poll driver release TID · 0a1cb809
      Johannes Berg 提交于
      Using ffs() for the PS-Poll release TID is wrong, it will cause
      frames to be released in order 0 1 2 3 4 5 6 7 instead of the
      correct 7 6 5 4 3 0 2 1. Fix this by adding a new function that
      implements "highest priority TID" properly.
      Reported-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      0a1cb809
  4. 07 1月, 2014 6 次提交
  5. 06 1月, 2014 4 次提交
  6. 31 12月, 2013 1 次提交
  7. 27 12月, 2013 1 次提交
  8. 19 12月, 2013 6 次提交
  9. 18 12月, 2013 2 次提交
  10. 17 12月, 2013 1 次提交
  11. 16 12月, 2013 12 次提交