1. 14 5月, 2014 18 次提交
  2. 13 5月, 2014 4 次提交
  3. 11 5月, 2014 1 次提交
    • E
      iwlwifi: mvm: fix setting channel in monitor mode · 1c4abec0
      Emmanuel Grumbach 提交于
      There was a deadlock in monitor mode when we were setting the
      channel if the channel was not 1.
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.14.3 #4 Not tainted
      -------------------------------------------------------
      iw/3323 is trying to acquire lock:
       (&local->chanctx_mtx){+.+.+.}, at: [<ffffffffa062e2f2>] ieee80211_vif_release_channel+0x42/0xb0 [mac80211]
      
      but task is already holding lock:
       (&local->iflist_mtx){+.+...}, at: [<ffffffffa0609e0a>] ieee80211_set_monitor_channel+0x5a/0x1b0 [mac80211]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 (&local->iflist_mtx){+.+...}:
             [<ffffffff810d95bb>] __lock_acquire+0xb3b/0x13b0
             [<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0
             [<ffffffff817eb9c8>] mutex_lock_nested+0x78/0x4f0
             [<ffffffffa06225cf>] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
             [<ffffffffa0518189>] iwl_mvm_recalc_multicast+0x49/0xa0 [iwlmvm]
             [<ffffffffa051822e>] iwl_mvm_configure_filter+0x4e/0x70 [iwlmvm]
             [<ffffffffa05e6d43>] ieee80211_configure_filter+0x153/0x5f0 [mac80211]
             [<ffffffffa05e71f5>] ieee80211_reconfig_filter+0x15/0x20 [mac80211]
             [snip]
      
      -> #1 (&mvm->mutex){+.+.+.}:
             [<ffffffff810d95bb>] __lock_acquire+0xb3b/0x13b0
             [<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0
             [<ffffffff817eb9c8>] mutex_lock_nested+0x78/0x4f0
             [<ffffffffa0517246>] iwl_mvm_add_chanctx+0x56/0xe0 [iwlmvm]
             [<ffffffffa062ca1e>] ieee80211_new_chanctx+0x13e/0x410 [mac80211]
             [<ffffffffa062d953>] ieee80211_vif_use_channel+0x1c3/0x5a0 [mac80211]
             [<ffffffffa06035ab>] ieee80211_add_virtual_monitor+0x1ab/0x6b0 [mac80211]
             [<ffffffffa06052ea>] ieee80211_do_open+0xe6a/0x15a0 [mac80211]
             [<ffffffffa0605a79>] ieee80211_open+0x59/0x60 [mac80211]
             [snip]
      
      -> #0 (&local->chanctx_mtx){+.+.+.}:
             [<ffffffff810d6cb7>] check_prevs_add+0x977/0x980
             [<ffffffff810d95bb>] __lock_acquire+0xb3b/0x13b0
             [<ffffffff810d9ee0>] lock_acquire+0xb0/0x1f0
             [<ffffffff817eb9c8>] mutex_lock_nested+0x78/0x4f0
             [<ffffffffa062e2f2>] ieee80211_vif_release_channel+0x42/0xb0 [mac80211]
             [<ffffffffa0609ec3>] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211]
             [<ffffffffa058fb37>] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211]
             [<ffffffffa056e0b2>] __nl80211_set_channel+0x122/0x140 [cfg80211]
             [<ffffffffa0581374>] nl80211_set_wiphy+0x284/0xaf0 [cfg80211]
             [snip]
      
      other info that might help us debug this:
      
      Chain exists of:
        &local->chanctx_mtx --> &mvm->mutex --> &local->iflist_mtx
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&local->iflist_mtx);
                                     lock(&mvm->mutex);
                                     lock(&local->iflist_mtx);
        lock(&local->chanctx_mtx);
      
       *** DEADLOCK ***
      
      This deadlock actually occurs:
      INFO: task iw:3323 blocked for more than 120 seconds.
            Not tainted 3.14.3 #4
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      iw              D ffff8800c8afcd80  4192  3323   3322 0x00000000
       ffff880078fdb7e0 0000000000000046 ffff8800c8afcd80 ffff880078fdbfd8
       00000000001d5540 00000000001d5540 ffff8801141b0000 ffff8800c8afcd80
       ffff880078ff9e38 ffff880078ff9e38 ffff880078ff9e40 0000000000000246
      Call Trace:
       [<ffffffff817ea841>] schedule_preempt_disabled+0x31/0x80
       [<ffffffff817ebaed>] mutex_lock_nested+0x19d/0x4f0
       [<ffffffffa06225cf>] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
       [<ffffffffa06225cf>] ? ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
       [<ffffffffa052a680>] ? iwl_mvm_power_mac_update_mode+0xc0/0xc0 [iwlmvm]
       [<ffffffffa06225cf>] ieee80211_iterate_active_interfaces+0x2f/0x60 [mac80211]
       [<ffffffffa0529357>] _iwl_mvm_power_update_binding+0x27/0x80 [iwlmvm]
       [<ffffffffa0516eb1>] iwl_mvm_unassign_vif_chanctx+0x81/0xc0 [iwlmvm]
       [<ffffffffa062d3ff>] __ieee80211_vif_release_channel+0xdf/0x470 [mac80211]
       [<ffffffffa062e2fa>] ieee80211_vif_release_channel+0x4a/0xb0 [mac80211]
       [<ffffffffa0609ec3>] ieee80211_set_monitor_channel+0x113/0x1b0 [mac80211]
       [<ffffffffa058fb37>] cfg80211_set_monitor_channel+0x77/0x2b0 [cfg80211]
       [<ffffffffa056e0b2>] __nl80211_set_channel+0x122/0x140 [cfg80211]
       [<ffffffffa0581374>] nl80211_set_wiphy+0x284/0xaf0 [cfg80211]
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=75541
      
      Cc: <stable@vger.kernel.org> [3.13+]
      Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      1c4abec0
  4. 09 5月, 2014 2 次提交
    • E
      mac80211: fix vif name tracing · f9ac71bf
      Eliad Peller 提交于
      If sdata doesn't have a valid dev (e.g. in case of monitor
      vif), the vif_name field was initialized with (a length of)
      some short string, but later was set to a different,
      potentially larger one.
      
      This resulted in out-of-bounds write, which usually
      appeared as garbage in the trace log.
      
      Simply trace sdata->name, as it should always have the
      correct name for both cases.
      Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f9ac71bf
    • J
      mac80211: allow VHT with peers not capable of 40MHz · 4a817aa7
      Johannes Berg 提交于
      There are two (related) issues with this.
      
      One case, reported by Michal, is related to hostap: it unsets the
      20/40 capability bit for stations that associate when it's in 20
      MHz mode.
      
      The other case, reported by Eyal, is that some APs like Netgear
      R6300v2 and probably others based on the BCM4360 chipset can be
      configured for doing VHT at 20Mhz. In this case the beacon has
      a VHT IE but the HT cap indicates transmitter only support 20Mhz.
      
      In both of these cases, we currently avoid VHT and use only HT
      this means we can't use the highest rates (MCS8), so fixing this
      leads to throughput improvements.
      Reported-by: NMichal Kazior <michal.kazior@tieto.com>
      Reported-by: NEyal Shapira <eyal@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      4a817aa7
  5. 08 5月, 2014 12 次提交
  6. 07 5月, 2014 3 次提交