1. 10 12月, 2010 1 次提交
    • N
      net: Convert netpoll blocking api in bonding driver to be a counter · fb4fa76a
      Neil Horman 提交于
      A while back I made some changes to enable netpoll in the bonding driver.  Among
      them was a per-cpu flag that indicated we were in a path that held locks which
      could cause the netpoll path to block in during tx, and as such the tx path
      should queue the frame for later use.  This appears to have given rise to a
      regression.  If one of those paths on which we hold the per-cpu flag yields the
      cpu, its possible for us to come back on a different cpu, leading to us clearing
      a different flag than we set.  This results in odd netpoll drops, and BUG
      backtraces appearing in the log, as we check to make sure that we only clear set
      bits, and only set clear bits.  I had though briefly about changing the
      offending paths so that they wouldn't sleep, but looking at my origional work
      more closely, it doesn't appear that a per-cpu flag is warranted.  We alrady
      gate the checking of this flag on IFF_IN_NETPOLL, so we don't hit this in the
      normal tx case anyway.  And practically speaking, the normal use case for
      netpoll is to only have one client anyway, so we're not going to erroneously
      queue netpoll frames when its actually safe to do so.  As such, lets just
      convert that per-cpu flag to an atomic counter.  It fixes the rescheduling bugs,
      is equivalent from a performance perspective and actually eliminates some code
      in the process.
      
      Tested by the reporter and myself, successfully
      Reported-by: NLiang Zheng <lzheng@redhat.com>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: David S. Miller <davem@davemloft.net>
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fb4fa76a
  2. 09 12月, 2010 16 次提交
  3. 08 12月, 2010 2 次提交
  4. 07 12月, 2010 2 次提交
  5. 03 12月, 2010 7 次提交
  6. 02 12月, 2010 6 次提交
  7. 01 12月, 2010 4 次提交
    • S
      ath9k: Fix STA disconnect issue due to received MIC failed bcast frames · 916448e7
      Senthil Balasubramanian 提交于
      AR_RxKeyIdxValid will not be set for bcast/mcast frames and so relying
      this status for MIC failed frames is buggy.
      
      Due to this, MIC failure events for broadcast frames are not sent to
      supplicant resulted in AP disconnecting the STA.
      
      Able to pass Wifi Test case 5.2.18 with this fix.
      
      Cc: Stable <stable@kernel.org> (2.6.36+)
      Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      916448e7
    • S
      mac80211: Fix STA disconnect due to MIC failure · 8e26d5ad
      Senthil Balasubramanian 提交于
      Th commit titled "mac80211: clean up rx handling wrt. found_sta"
      removed found_sta variable which caused a MIC failure event
      to be reported twice for a single failure to supplicant resulted
      in STA disconnect.
      
      This should fix WPA specific countermeasures WiFi test case (5.2.17)
      issues with mac80211 based drivers which report MIC failure events in
      rx status.
      
      Cc: Stable <stable@kernel.org> (2.6.37)
      Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8e26d5ad
    • C
      mac80211: ignore non-bcast mcast deauth/disassoc franes · 2c31333a
      Christian Lamparter 提交于
      This patch fixes an curious issue due to insufficient
      rx frame filtering.
      
      Saqeb Akhter reported frequent disconnects while streaming
      videos over samba: <http://marc.info/?m=128600031109136>
      > [ 1166.512087] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
      > [ 1526.059997] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
      > [ 2125.324356] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
      > [...]
      
      The reason is that the device generates frames with slightly
      bogus SA/TA addresses.
      
      e.g.:
       [ 2314.402316] Ignore 9f:1f:31:f8:64:ff
       [ 2314.402321] Ignore 9f:1f:31:f8:64:ff
       [ 2352.453804] Ignore 0d:1f:31:f8:64:ff
       [ 2352.453808] Ignore 0d:1f:31:f8:64:ff
       					   ^^ the group-address flag is set!
       (the correct SA/TA would be: 00:1f:31:f8:64:ff)
      
      Since the AP does not know from where the frames come, it
      generates a DEAUTH response for the (invalid) mcast address.
      This mcast deauth frame then passes through all filters and
      tricks the stack into thinking that the AP brutally kicked
      us!
      
      This patch fixes the problem by simply ignoring
      non-broadcast, group-addressed deauth/disassoc frames.
      
      Cc: Jouni Malinen <j@w1.fi>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Reported-by: NSaqeb Akhter <saqeb.akhter@gmail.com>
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2c31333a
    • D
      orinoco: abort scan on interface down · cf63495d
      David Kilroy 提交于
      This fixes the problem causing the following trace:
      
      ------------[ cut here ]------------
      WARNING: at linux-2.6.34/net/wireless/core.c:633 wdev_cleanup_work+0xb7/0xe0 [cfg80211]()
      Hardware name: Latitude C840
      Pid: 707, comm: cfg80211 Not tainted 2.6.34.7-0.5-desktop #1
      Call Trace:
       [<c02065c3>] try_stack_unwind+0x173/0x190
       [<c02051cf>] dump_trace+0x3f/0xe0
       [<c020662b>] show_trace_log_lvl+0x4b/0x60
       [<c0206658>] show_trace+0x18/0x20
       [<c064e0b3>] dump_stack+0x6d/0x72
       [<c02443ae>] warn_slowpath_common+0x6e/0xb0
       [<c0244403>] warn_slowpath_null+0x13/0x20
       [<e2db5497>] wdev_cleanup_work+0xb7/0xe0 [cfg80211]
       [<c025cfa9>] run_workqueue+0x79/0x170
       [<c025d123>] worker_thread+0x83/0xe0
       [<c025fef4>] kthread+0x74/0x80
       [<c0203826>] kernel_thread_helper+0x6/0x10
      ---[ end trace 3f0348b3b0c6f4ff ]---
      
      Reported by: Giacomo Comes <comes@naic.edu>
      Signed-off-by: NDavid Kilroy <kilroyd@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cf63495d
  8. 30 11月, 2010 2 次提交