1. 10 Jun, 2012 1 commit
    • Paul Pluzhnikov's avatar
      net: Make linux/tcp.h C++ friendly (trivial) · 8876d6b5
      Paul Pluzhnikov authored
      I originally sent this patch to <trivial@kernel.org>, but Jiri Kosina did
      not feel that this is fully appropriate for the trivial tree.
      
      Using linux/tcp.h from C++ results in:
      
      cat t.cc
      #include <linux/tcp.h>
      int main() { }
      
      g++ -c t.cc
      
      In file included from t.cc:1:
      /usr/include/linux/tcp.h:72: error: '__u32 __fswab32(__u32)' cannot appear in a constant-expression
      /usr/include/linux/tcp.h:72: error: a function call cannot appear in a constant-expression
      ...
      
      Attached trivial patch fixes this problem.
      
      Tested:
      - the t.cc above compiles with g++ and
      - the following program generates the same output before/after
        the patch:
      
      #include <linux/tcp.h>
      #include <stdio.h>
      
      int main ()
      {
      #define P(a) printf("%s: %08x\n", #a, (int)a)
       P(TCP_FLAG_CWR);
       P(TCP_FLAG_ECE);
       P(TCP_FLAG_URG);
       P(TCP_FLAG_ACK);
       P(TCP_FLAG_PSH);
       P(TCP_FLAG_RST);
       P(TCP_FLAG_SYN);
       P(TCP_FLAG_FIN);
       P(TCP_RESERVED_BITS);
       P(TCP_DATA_OFFSET);
      #undef P
       return 0;
      }
      Signed-off-by: default avatarPaul Pluzhnikov <ppluzhnikov@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8876d6b5
  2. 09 Jun, 2012 2 commits
  3. 08 Jun, 2012 4 commits
  4. 07 Jun, 2012 6 commits
  5. 06 Jun, 2012 12 commits
  6. 05 Jun, 2012 4 commits
  7. 04 Jun, 2012 11 commits
    • Johannes Berg's avatar
      iwlwifi: disable WoWLAN if !CONFIG_PM_SLEEP · fcb6ff5e
      Johannes Berg authored
      If CONFIG_PM_SLEEP is disabled, then iwlwifi doesn't
      support suspend/resume handlers and thus mac80211
      (correctly) refuses advertising WoWLAN. Disable
      WoWLAN in the driver in this case.
      
      Cc: stable@kernel.org
      Reported-by: default avatarSebastian Kemper <sebastian_ml@gmx.net>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      fcb6ff5e
    • Arik Nemtsov's avatar
      mac80211: fix non RCU-safe sta_list manipulation · 794454ce
      Arik Nemtsov authored
      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: default avatarEyal Shapira <eyal@wizery.com>
      Signed-off-by: default avatarArik Nemtsov <arik@wizery.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      794454ce
    • Seth Forshee's avatar
      bcma: add ext PA workaround for BCM4331 and BCM43431 · 69aaedd3
      Seth Forshee authored
      MacBook Pro models with BCM4331 wireless have been found to have the ext
      PA lines disabled after resuming from S3 without external power attach.
      This causes them to be unable to transmit. Add a workaround to ensure
      that the ext PA lines are enabled on BCM4331. Also extend all handling
      of ext PA line muxing to BCM43431 as is done in the Broadcom SDK.
      
      BugLink: http://bugs.launchpad.net/bugs/925577
      Cc: Arend van Spriel <arend@broadcom.com>
      Cc: Hauke Mehrtens <hauke@hauke-m.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      69aaedd3
    • Stanislaw Gruszka's avatar
      rt2x00: use atomic variable for seqno · e5851dac
      Stanislaw Gruszka authored
      Remove spinlock as atomic_t can be used instead. Note we use only 16
      lower bits, upper bits are changed but we impilcilty cast to u16.
      
      This fix possible deadlock on IBSS mode reproted by lockdep:
      
      =================================
      [ INFO: inconsistent lock state ]
      3.4.0-wl+ #4 Not tainted
      ---------------------------------
      inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
      kworker/u:2/30374 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (&(&intf->seqlock)->rlock){+.?...}, at: [<f9979a20>] rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
      {IN-SOFTIRQ-W} state was registered at:
        [<c04978ab>] __lock_acquire+0x47b/0x1050
        [<c0498504>] lock_acquire+0x84/0xf0
        [<c0835733>] _raw_spin_lock+0x33/0x40
        [<f9979a20>] rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
        [<f9979f2a>] rt2x00queue_write_tx_frame+0x1a/0x300 [rt2x00lib]
        [<f997834f>] rt2x00mac_tx+0x7f/0x380 [rt2x00lib]
        [<f98fe363>] __ieee80211_tx+0x1b3/0x300 [mac80211]
        [<f98ffdf5>] ieee80211_tx+0x105/0x130 [mac80211]
        [<f99000dd>] ieee80211_xmit+0xad/0x100 [mac80211]
        [<f9900519>] ieee80211_subif_start_xmit+0x2d9/0x930 [mac80211]
        [<c0782e87>] dev_hard_start_xmit+0x307/0x660
        [<c079bb71>] sch_direct_xmit+0xa1/0x1e0
        [<c0784bb3>] dev_queue_xmit+0x183/0x730
        [<c078c27a>] neigh_resolve_output+0xfa/0x1e0
        [<c07b436a>] ip_finish_output+0x24a/0x460
        [<c07b4897>] ip_output+0xb7/0x100
        [<c07b2d60>] ip_local_out+0x20/0x60
        [<c07e01ff>] igmpv3_sendpack+0x4f/0x60
        [<c07e108f>] igmp_ifc_timer_expire+0x29f/0x330
        [<c04520fc>] run_timer_softirq+0x15c/0x2f0
        [<c0449e3e>] __do_softirq+0xae/0x1e0
      irq event stamp: 18380437
      hardirqs last  enabled at (18380437): [<c0526027>] __slab_alloc.clone.3+0x67/0x5f0
      hardirqs last disabled at (18380436): [<c0525ff3>] __slab_alloc.clone.3+0x33/0x5f0
      softirqs last  enabled at (18377616): [<c0449eb3>] __do_softirq+0x123/0x1e0
      softirqs last disabled at (18377611): [<c041278d>] do_softirq+0x9d/0xe0
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&(&intf->seqlock)->rlock);
        <Interrupt>
          lock(&(&intf->seqlock)->rlock);
      
       *** DEADLOCK ***
      
      4 locks held by kworker/u:2/30374:
       #0:  (wiphy_name(local->hw.wiphy)){++++.+}, at: [<c045cf99>] process_one_work+0x109/0x3f0
       #1:  ((&sdata->work)){+.+.+.}, at: [<c045cf99>] process_one_work+0x109/0x3f0
       #2:  (&ifibss->mtx){+.+.+.}, at: [<f98f005b>] ieee80211_ibss_work+0x1b/0x470 [mac80211]
       #3:  (&intf->beacon_skb_mutex){+.+...}, at: [<f997a644>] rt2x00queue_update_beacon+0x24/0x50 [rt2x00lib]
      
      stack backtrace:
      Pid: 30374, comm: kworker/u:2 Not tainted 3.4.0-wl+ #4
      Call Trace:
       [<c04962a6>] print_usage_bug+0x1f6/0x220
       [<c0496a12>] mark_lock+0x2c2/0x300
       [<c0495ff0>] ? check_usage_forwards+0xc0/0xc0
       [<c04978ec>] __lock_acquire+0x4bc/0x1050
       [<c0527890>] ? __kmalloc_track_caller+0x1c0/0x1d0
       [<c0777fb6>] ? copy_skb_header+0x26/0x90
       [<c0498504>] lock_acquire+0x84/0xf0
       [<f9979a20>] ? rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
       [<c0835733>] _raw_spin_lock+0x33/0x40
       [<f9979a20>] ? rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
       [<f9979a20>] rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
       [<f997a5cf>] rt2x00queue_update_beacon_locked+0x5f/0xb0 [rt2x00lib]
       [<f997a64d>] rt2x00queue_update_beacon+0x2d/0x50 [rt2x00lib]
       [<f9977e3a>] rt2x00mac_bss_info_changed+0x1ca/0x200 [rt2x00lib]
       [<f9977c70>] ? rt2x00mac_remove_interface+0x70/0x70 [rt2x00lib]
       [<f98e4dd0>] ieee80211_bss_info_change_notify+0xe0/0x1d0 [mac80211]
       [<f98ef7b8>] __ieee80211_sta_join_ibss+0x3b8/0x610 [mac80211]
       [<c0496ab4>] ? mark_held_locks+0x64/0xc0
       [<c0440012>] ? virt_efi_query_capsule_caps+0x12/0x50
       [<f98efb09>] ieee80211_sta_join_ibss+0xf9/0x140 [mac80211]
       [<f98f0456>] ieee80211_ibss_work+0x416/0x470 [mac80211]
       [<c0496d8b>] ? trace_hardirqs_on+0xb/0x10
       [<c077683b>] ? skb_dequeue+0x4b/0x70
       [<f98f207f>] ieee80211_iface_work+0x13f/0x230 [mac80211]
       [<c045cf99>] ? process_one_work+0x109/0x3f0
       [<c045d015>] process_one_work+0x185/0x3f0
       [<c045cf99>] ? process_one_work+0x109/0x3f0
       [<f98f1f40>] ? ieee80211_teardown_sdata+0xa0/0xa0 [mac80211]
       [<c045ed86>] worker_thread+0x116/0x270
       [<c045ec70>] ? manage_workers+0x1e0/0x1e0
       [<c0462f64>] kthread+0x84/0x90
       [<c0462ee0>] ? __init_kthread_worker+0x60/0x60
       [<c083d382>] kernel_thread_helper+0x6/0x10
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Acked-by: default avatarHelmut Schaa <helmut.schaa@googlemail.com>
      Acked-by: default avatarGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e5851dac
    • Joe Perches's avatar
      brcmfmac: Fix likely misuse of | for & · f304a993
      Joe Perches authored
      Using | with a constant is always true.
      Likely this should have be &.
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Acked-by: default avatarArend van Spriel <arend@broadcom.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f304a993
    • Joe Perches's avatar
      mac80211: Fix likely misuse of | for & · 5204267d
      Joe Perches authored
      Using | with a constant is always true.
      Likely this should have be &.
      
      cc: Ben Greear <greearb@candelatech.com>
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5204267d
    • Felix Fietkau's avatar
      mac80211: add missing rcu_read_lock/unlock in agg-rx session timer · d8c7aae6
      Felix Fietkau authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d8c7aae6
    • Johannes Berg's avatar
      mac80211: clean up remain-on-channel on interface stop · 71ecfa18
      Johannes Berg authored
      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: default avatarNirav Shah <nirav.j2.shah@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      71ecfa18
    • Johannes Berg's avatar
      mac80211_hwsim: advertise interface combinations · 1ae2fc25
      Johannes Berg authored
      Enforcing interface combinations broke uses of hwsim
      with multiple virtual interfaces. Advertise that all
      combinations are possible to fix this.
      Reported-by: default avatarNirav Shah <nirav.j2.shah@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      1ae2fc25
    • Meenakshi Venkataraman's avatar
      mac80211: fix error in station state transitions during reconfig · bd34ab62
      Meenakshi Venkataraman authored
      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: default avatarMeenakshi Venkataraman <meenakshi.venkataraman@intel.com>
      Reviewed-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      bd34ab62
    • Johannes Berg's avatar
      iwlwifi: fix TX power antenna access · a5fdde28
      Johannes Berg authored
      Since my commit
        iwlwifi: use valid TX/RX antenna from hw_params
      the config values are pure overrides, not the
      real values for all hardware. Therefore, the
      EEPROM TX power reading code checks the wrong
      values, it should check the hw_params values.
      
      Cc: stable@kernel.org [3.4]
      Reviewed-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a5fdde28