1. 14 3月, 2012 1 次提交
  2. 13 3月, 2012 10 次提交
  3. 08 3月, 2012 3 次提交
    • T
      mac80211: fix smatch lock errors in mesh · f06c7885
      Thomas Pedersen 提交于
      smatch was complaining:
      
      CHECK   net/mac80211/mesh_pathtbl.c
      net/mac80211/mesh_pathtbl.c:562 mesh_path_add() error: double lock
      'bottom_half:'
      net/mac80211/mesh_pathtbl.c:580 mesh_path_add() error: double unlock
      'bottom_half:'
      net/mac80211/mesh_pathtbl.c:589 mesh_path_add() error: double unlock
      'bottom_half:'
      net/mac80211/mesh_pathtbl.c:691 mpp_path_add() error: double lock
      'bottom_half:'
      net/mac80211/mesh_pathtbl.c:707 mpp_path_add() error: double unlock
      'bottom_half:'
      net/mac80211/mesh_pathtbl.c:716 mpp_path_add() error: double unlock
      'bottom_half:'
      net/mac80211/mesh_pathtbl.c:814 mesh_path_flush_by_nexthop() error:
      double lock 'bottom_half:'
      net/mac80211/mesh_pathtbl.c:819 mesh_path_flush_by_nexthop() error:
      double unlock 'bottom_half:'
      net/mac80211/mesh_pathtbl.c:887 mesh_path_del() error: double lock
      'bottom_half:'
      net/mac80211/mesh_pathtbl.c:901 mesh_path_del() error: double unlock
      'bottom_half:'
      
      So don't lock / unlock with _bh() while bottom halves are already
      disabled.
      Reported-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f06c7885
    • A
      mac80211: Fix potential null pointer dereferencing · 3d4f9699
      Ashok Nagarajan 提交于
      The patch "{nl,cfg,mac}80211: Implement RSSI threshold for mesh peering"
      has a potential null pointer dereferencing problem. Thanks to Dan Carpenter
      for pointing out. This patch will fix the issue.
      Signed-off-by: NAshok Nagarajan <ashok@cozybit.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3d4f9699
    • P
      mac80211: Filter duplicate IE ids · fcff4f10
      Paul Stewart 提交于
      mac80211 is lenient with respect to reception of corrupted beacons.
      Even if the frame is corrupted as a whole, the available IE elements
      are still passed back and accepted, sometimes replacing legitimate
      data.  It is unknown to what extent this "feature" is made use of,
      but it is clear that in some cases, this is detrimental.  One such
      case is reported in http://crosbug.com/26832 where an AP corrupts
      its beacons but not its probe responses.
      
      One approach would be to completely reject frames with invaid data
      (for example, if the last tag extends beyond the end of the enclosing
      PDU).  The enclosed approach is much more conservative: we simply
      prevent later IEs from overwriting the state from previous ones.
      This approach hopes that there might be some salient data in the
      IE stream before the corruption, and seeks to at least prevent that
      data from being overwritten.  This approach will fix the case above.
      
      Further, we flag element structures that contain data we think might
      be corrupted, so that as we fill the mac80211 BSS structure, we try
      not to replace data from an un-corrupted probe response with that
      of a corrupted beacon, for example.
      
      Short of any statistics gathering in the various forms of AP breakage,
      it's not possible to ascertain the side effects of more stringent
      discarding of data.
      Signed-off-by: NPaul Stewart <pstew@chromium.org>
      Cc: Sam Leffler <sleffler@chromium.org>
      Cc: Eliad Peller <eliad@wizery.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fcff4f10
  4. 07 3月, 2012 3 次提交
  5. 06 3月, 2012 8 次提交
  6. 01 3月, 2012 5 次提交
  7. 28 2月, 2012 8 次提交
  8. 23 2月, 2012 1 次提交
  9. 22 2月, 2012 1 次提交
    • M
      mac80211: Fix a warning on changing to monitor mode from STA · 0dee0068
      Mohammed Shafi Shajakhan 提交于
      nothing needs to be done for monitor/AP_VLAN mode on calling
      ieee80211_bss_info_change_notify -> drv_bss_info_changed with the change
      flag 'BSS_CHANGED_IDLE'. 'wl1271' seems to use BSS_CHANGED_IDLE only for
      STA and IBSS mode. further the non-idle state of the monitor mode is
      taken care by the 'count' variable which counts non-idle interfaces.
      ieee80211_idle_off(local, "in use") will be called.
      this fixes the following WARNING when we have initially STA mode
      (network manager running) and not associated, and change it to monitor
      mode with network manager disabled and bringing up the monitor mode.
      this changes the idle state from 'true' (STA unassociated) to 'false'
      (MONITOR mode)
      exposed by the commit 405385f8
      "mac80211: set bss_conf.idle when vif is connected"
      
      	WARNING: net/mac80211/main.c:212
      	ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]()
      	Hardware name: 64756D6
      	Pid: 3835, comm: ifconfig Tainted: G           O
      	3.3.0-rc3-wl #9
      	Call Trace:
      	  [<c0133b02>] warn_slowpath_common+0x72/0xa0
      	  [<fc8e8c3f>] ?
      	  ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]
      	  [<fc8e8c3f>] ?
      	  ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]
      	  [<c0133b52>] warn_slowpath_null+0x22/0x30
      	  [<fc8e8c3f>]
      	  ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]
      	  [<fc8f9de3>] __ieee80211_recalc_idle+0x113/0x430
      	  [mac80211]
      	  [<fc8fabc6>] ieee80211_do_open+0x156/0x7e0 [mac80211]
      	  [<fc8f8a25>] ?
      	  ieee80211_check_concurrent_iface+0x25/0x180 [mac80211]
      	  [<c015dd9f>] ? raw_notifier_call_chain+0x1f/0x30
      	  [<fc8fb290>] ieee80211_open+0x40/0x80 [mac80211]
      	  [<c05894f6>] __dev_open+0x96/0xe0
      	  [<c068fba5>] ? _raw_spin_unlock_bh+0x35/0x40
      	  [<c05881d9>] __dev_change_flags+0x109/0x170
      	  [<c0589423>] dev_change_flags+0x23/0x60
      	  [<c05f3770>] devinet_ioctl+0x6a0/0x770
      
       ieee80211 phy0: device no longer idle - in use
      
      Cc: Eliad Peller <eliad@wizery.com>
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0dee0068