1. 07 6月, 2012 4 次提交
  2. 06 6月, 2012 15 次提交
  3. 05 6月, 2012 7 次提交
    • A
      mac80211: fix non RCU-safe sta_list manipulation · 794454ce
      Arik Nemtsov 提交于
      sta_info_cleanup locks the sta_list using rcu_read_lock however
      the delete operation isn't rcu safe. A race between sta_info_cleanup
      timer being called and a STA being removed can occur which leads
      to a panic while traversing sta_list. Fix this by switching to the
      RCU-safe versions.
      
      Cc: stable@vger.kernel.org
      Reported-by: NEyal Shapira <eyal@wizery.com>
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      794454ce
    • J
      mac80211: Fix likely misuse of | for & · 5204267d
      Joe Perches 提交于
      Using | with a constant is always true.
      Likely this should have be &.
      
      cc: Ben Greear <greearb@candelatech.com>
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5204267d
    • F
      mac80211: add missing rcu_read_lock/unlock in agg-rx session timer · d8c7aae6
      Felix Fietkau 提交于
      Fixes a lockdep warning:
      
      ===================================================
      [ INFO: suspicious rcu_dereference_check() usage. ]
      ---------------------------------------------------
      net/mac80211/agg-rx.c:148 invoked rcu_dereference_check() without protection!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 1, debug_locks = 1
      1 lock held by arecord/11226:
       #0:  (&tid_agg_rx->session_timer){+.-...}, at: [<ffffffff81066bb0>] call_timer_fn+0x0/0x360
      
      stack backtrace:
      Pid: 11226, comm: arecord Not tainted 3.1.0-kml #16
      Call Trace:
       <IRQ>  [<ffffffff81093454>] lockdep_rcu_dereference+0xa4/0xc0
       [<ffffffffa02778c9>] sta_rx_agg_session_timer_expired+0xc9/0x110 [mac80211]
       [<ffffffffa0277800>] ? ieee80211_process_addba_resp+0x220/0x220 [mac80211]
       [<ffffffff81066c3a>] call_timer_fn+0x8a/0x360
       [<ffffffff81066bb0>] ? init_timer_deferrable_key+0x30/0x30
       [<ffffffff81477bb0>] ? _raw_spin_unlock_irq+0x30/0x70
       [<ffffffff81067049>] run_timer_softirq+0x139/0x310
       [<ffffffff81091d5e>] ? put_lock_stats.isra.25+0xe/0x40
       [<ffffffff810922ac>] ? lock_release_holdtime.part.26+0xdc/0x160
       [<ffffffffa0277800>] ? ieee80211_process_addba_resp+0x220/0x220 [mac80211]
       [<ffffffff8105cb78>] __do_softirq+0xc8/0x3c0
       [<ffffffff8108f088>] ? tick_dev_program_event+0x48/0x110
       [<ffffffff8108f16f>] ? tick_program_event+0x1f/0x30
       [<ffffffff81153b15>] ? putname+0x35/0x50
       [<ffffffff8147a43c>] call_softirq+0x1c/0x30
       [<ffffffff81004c55>] do_softirq+0xa5/0xe0
       [<ffffffff8105d1ee>] irq_exit+0xae/0xe0
       [<ffffffff8147ac6b>] smp_apic_timer_interrupt+0x6b/0x98
       [<ffffffff81479ab3>] apic_timer_interrupt+0x73/0x80
       <EOI>  [<ffffffff8146aac6>] ? free_debug_processing+0x1a1/0x1d5
       [<ffffffff81153b15>] ? putname+0x35/0x50
       [<ffffffff8146ab2b>] __slab_free+0x31/0x2ca
       [<ffffffff81477c3a>] ? _raw_spin_unlock_irqrestore+0x4a/0x90
       [<ffffffff81253b8f>] ? __debug_check_no_obj_freed+0x15f/0x210
       [<ffffffff81097054>] ? lock_release_nested+0x84/0xc0
       [<ffffffff8113ec55>] ? kmem_cache_free+0x105/0x250
       [<ffffffff81153b15>] ? putname+0x35/0x50
       [<ffffffff81153b15>] ? putname+0x35/0x50
       [<ffffffff8113ed8f>] kmem_cache_free+0x23f/0x250
       [<ffffffff81153b15>] putname+0x35/0x50
       [<ffffffff81146d8d>] do_sys_open+0x16d/0x1d0
       [<ffffffff81146e10>] sys_open+0x20/0x30
       [<ffffffff81478f42>] system_call_fastpath+0x16/0x1b
      Reported-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d8c7aae6
    • J
      mac80211: clean up remain-on-channel on interface stop · 71ecfa18
      Johannes Berg 提交于
      When any interface goes down, it could be the one that we
      were doing a remain-on-channel with. We therefore need to
      cancel the remain-on-channel and flush the related work
      structs so they don't run after the interface has been
      removed or even destroyed.
      
      It's also possible in this case that an off-channel SKB
      was never transmitted, so free it if this is the case.
      Note that this can also happen if the driver finishes
      the off-channel period without ever starting it.
      
      Cc: stable@kernel.org
      Reported-by: NNirav Shah <nirav.j2.shah@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      71ecfa18
    • M
      mac80211: fix error in station state transitions during reconfig · bd34ab62
      Meenakshi Venkataraman 提交于
      As part of hardware reconfig mac80211 tries
      to restore the station state to its values
      before the hardware reconfig, but it only
      goes to the last-state - 1. Fix this
      off-by-one error.
      
      Cc: stable@kernel.org [3.4]
      Signed-off-by: NMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bd34ab62
    • C
      mac80211: Fix Unreachable Mesh Station Problem when joining to another MBSS · b8bacc18
      Chun-Yeow Yeoh 提交于
      Mesh station that joins an MBSS is reachable using mesh portal with 6
      address frame by mesh stations from another MBSS if these two different
      MBSSes are bridged. However, if the mesh station later moves into the
      same MBSS of those mesh stations, it is unreachable by mesh stations
      in the MBSS due to the mpp_paths table is not deleted. A quick fix
      is to perform mesh_path_lookup, if it is available for the target
      destination, mpp_path_lookup is not performed. When the mesh station
      moves back to its original MBSS, the mesh_paths will be deleted once
      expired. So, it will be reachable using mpp_path_lookup again.
      Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b8bacc18
    • S
      mac80211: run scan after finish connection monitoring · 925e64c3
      Stanislaw Gruszka 提交于
      commit 133d40f9
      Author: Stanislaw Gruszka <sgruszka@redhat.com>
      Date:   Wed Mar 28 16:01:19 2012 +0200
      
          mac80211: do not scan and monitor connection in parallel
      
      add bug, which make possible to start a scan and never finish it, so
      make every new scanning request finish with -EBUSY error. This can
      happen on code paths where we finish connection monitoring and clear
      IEEE80211_STA_*_POLL flags, but do not check if scan was deferred.
      This patch fixes those code paths.
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      925e64c3
  4. 30 5月, 2012 2 次提交
  5. 25 5月, 2012 1 次提交
    • S
      mac80211: Fix race in checking AP status by sending null frame · 992e68bf
      Soumik Das 提交于
      mac80211 tries to verify the existence of the current AP by
      probing or sending a NULL frame in function
      ieee80211_mgd_probe_ap_send. It 1st sends a null frame to the AP,
      increments probe_send_count and waits for the ACK to the NULL
      frame for a finite duration of time. At times, it happens that by
      the time mac80211 gets to increment probe_send_count, the ACK for
      the NULL frame transmitted has already been processed. This leads
      to a race condition where mac80211 times out waiting for the ACK
      for the NULL frame causing unnecessary disconnection with the AP.
      Signed-off-by: NSoumik Das <soumik.das@stericsson.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      992e68bf
  6. 17 5月, 2012 9 次提交
  7. 16 5月, 2012 2 次提交