1. 10 Dec, 2010 2 commits
    • Thomas Egerer's avatar
      xfrm: Fix xfrm_state_migrate leak · 78347c8c
      Thomas Egerer authored
      xfrm_state_migrate calls kfree instead of xfrm_state_put to free
      a failed state. According to git commit 553f9118 this can cause
      memory leaks.
      Signed-off-by: default avatarThomas Egerer <thomas.egerer@secunet.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      78347c8c
    • Neil Horman's avatar
      net: Convert netpoll blocking api in bonding driver to be a counter · fb4fa76a
      Neil Horman authored
      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: default avatarLiang 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: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb4fa76a
  2. 09 Dec, 2010 1 commit
  3. 08 Dec, 2010 15 commits
  4. 07 Dec, 2010 2 commits
  5. 06 Dec, 2010 2 commits
  6. 02 Dec, 2010 7 commits
  7. 01 Dec, 2010 6 commits
  8. 30 Nov, 2010 4 commits
    • Senthil Balasubramanian's avatar
      ath9k: Fix STA disconnect issue due to received MIC failed bcast frames · 916448e7
      Senthil Balasubramanian authored
      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: default avatarSenthil Balasubramanian <senthilkumar@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      916448e7
    • Senthil Balasubramanian's avatar
      mac80211: Fix STA disconnect due to MIC failure · 8e26d5ad
      Senthil Balasubramanian authored
      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: default avatarSenthil Balasubramanian <senthilkumar@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      8e26d5ad
    • Christian Lamparter's avatar
      mac80211: ignore non-bcast mcast deauth/disassoc franes · 2c31333a
      Christian Lamparter authored
      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: default avatarSaqeb Akhter <saqeb.akhter@gmail.com>
      Signed-off-by: default avatarChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2c31333a
    • David Kilroy's avatar
      orinoco: abort scan on interface down · cf63495d
      David Kilroy authored
      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: default avatarDavid Kilroy <kilroyd@googlemail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      cf63495d
  9. 29 Nov, 2010 1 commit