1. 02 May, 2013 16 commits
  2. 19 Apr, 2013 4 commits
  3. 18 Apr, 2013 2 commits
  4. 17 Apr, 2013 2 commits
  5. 15 Apr, 2013 2 commits
  6. 14 Apr, 2013 1 commit
    • Cong Wang's avatar
      ipv6: statically link register_inet6addr_notifier() · f88c91dd
      Cong Wang authored
      
      Tomas reported the following build error:
      
      net/built-in.o: In function `ieee80211_unregister_hw':
      (.text+0x10f0e1): undefined reference to `unregister_inet6addr_notifier'
      net/built-in.o: In function `ieee80211_register_hw':
      (.text+0x10f610): undefined reference to `register_inet6addr_notifier'
      make: *** [vmlinux] Error 1
      
      when built IPv6 as a module.
      
      So we have to statically link these symbols.
      Reported-by: default avatarTomas Melin <tomas.melin@iki.fi>
      Cc: Tomas Melin <tomas.melin@iki.fi>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: YOSHIFUJI Hidaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarCong Wang <amwang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f88c91dd
  7. 12 Apr, 2013 2 commits
    • David Ward's avatar
      net/802/mrp: fix possible race condition when calling mrp_pdu_queue() · fb745e9a
      David Ward authored
      
      (Adapted from a very similar change to net/802/garp.c by Cong Wang.)
      
      mrp_pdu_queue() should ways be called with the applicant spin lock.
      mrp_uninit_applicant() only holds the rtnl lock which is not enough;
      a race is possible because mrp_rcv() is called in BH context:
      
      	mrp_rcv()
      	  |->mrp_pdu_parse_msg()
      	    |->mrp_pdu_parse_vecattr()
      	      |->mrp_pdu_parse_vecattr_event()
      	        |-> mrp_attr_event()
      	          |-> mrp_pdu_append_vecattr_event()
      	            |-> mrp_pdu_queue()
      
      Cc: Cong Wang <amwang@redhat.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid Ward <david.ward@ll.mit.edu>
      Acked-by: default avatarCong Wang <amwang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb745e9a
    • Florian Westphal's avatar
      netfilter: nf_nat: fix race when unloading protocol modules · c2d421e1
      Florian Westphal authored
      
      following oops was reported:
      RIP: 0010:[<ffffffffa03227f2>]  [<ffffffffa03227f2>] nf_nat_cleanup_conntrack+0x42/0x70 [nf_nat]
      RSP: 0018:ffff880202c63d40  EFLAGS: 00010246
      RAX: 0000000000000000 RBX: ffff8801ac7bec28 RCX: ffff8801d0eedbe0
      RDX: dead000000200200 RSI: 0000000000000011 RDI: ffffffffa03265b8
      [..]
      Call Trace:
       [..]
       [<ffffffffa02febed>] destroy_conntrack+0xbd/0x110 [nf_conntrack]
      
      Happens when a conntrack timeout expires right after first part
      of the nat cleanup has completed (bysrc hash removal), but before
      part 2 has completed (re-initialization of nat area).
      
      [ destroy callback tries to delete bysrc again ]
      
      Patrick suggested to just remove the affected conntracks -- the
      connections won't work properly anyway without nat transformation.
      
      So, lets do that.
      Reported-by: default avatarCAI Qian <caiqian@redhat.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Acked-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      c2d421e1
  8. 11 Apr, 2013 2 commits
  9. 10 Apr, 2013 1 commit
    • Johannes Berg's avatar
      mac80211: fix cfg80211 interaction on auth/assoc request · 7b119dc0
      Johannes Berg authored
      
      If authentication (or association with FT) is requested by
      userspace, mac80211 currently doesn't tell cfg80211 that it
      disconnected from the AP. That leaves inconsistent state:
      cfg80211 thinks it's connected while mac80211 thinks it's
      not. Typically this won't last long, as soon as mac80211
      reports the new association to cfg80211 the old one goes
      away. If, however, the new authentication or association
      doesn't succeed, then cfg80211 will forever think the old
      one still exists and will refuse attempts to authenticate
      or associate with the AP it thinks it's connected to.
      
      Anders reported that this leads to it taking a very long
      time to reconnect to a network, or never even succeeding.
      I tested this with an AP hacked to never respond to auth
      frames, and one that works, and with just those two the
      system never recovers because one won't work and cfg80211
      thinks it's connected to the other so refuses connections
      to it.
      
      To fix this, simply make mac80211 tell cfg80211 when it is
      no longer connected to the old AP, while authenticating or
      associating to a new one.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarAnders Kaseorg <andersk@mit.edu>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      7b119dc0
  10. 09 Apr, 2013 5 commits
  11. 08 Apr, 2013 3 commits