1. 13 May, 2014 36 commits
  2. 12 May, 2014 2 commits
  3. 11 May, 2014 1 commit
    • Emmanuel Grumbach's avatar
      iwlwifi: mvm: fix setting channel in monitor mode · 1c4abec0
      Emmanuel Grumbach authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      1c4abec0
  4. 09 May, 2014 1 commit
    • Eliad Peller's avatar
      mac80211: fix vif name tracing · f9ac71bf
      Eliad Peller authored
      
      
      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: default avatarEliad Peller <eliadx.peller@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f9ac71bf