1. 20 6月, 2011 1 次提交
  2. 17 6月, 2011 2 次提交
    • F
      IGMP snooping: set mrouters_only flag for IPv6 traffic properly · fc2af6c7
      Fernando Luis Vázquez Cao 提交于
      Upon reception of a MGM report packet the kernel sets the mrouters_only flag
      in a skb that is a clone of the original skb, which means that the bridge
      loses track of MGM packets (cb buffers are tied to a specific skb and not
      shared) and it ends up forwading join requests to the bridge interface.
      
      This can cause unexpected membership timeouts and intermitent/permanent loss
      of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]:
      
          A snooping switch should forward IGMP Membership Reports only to
          those ports where multicast routers are attached.
          [...]
          Sending membership reports to other hosts can result, for IGMPv1
          and IGMPv2, in unintentionally preventing a host from joining a
          specific multicast group.
      Signed-off-by: NFernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
      Signed-off-by: NDavid S. Miller <davem@conan.davemloft.net>
      fc2af6c7
    • F
      IGMP snooping: set mrouters_only flag for IPv4 traffic properly · 62b2bcb4
      Fernando Luis Vázquez Cao 提交于
      Upon reception of a IGMP/IGMPv2 membership report the kernel sets the
      mrouters_only flag in a skb that may be a clone of the original skb, which
      means that sometimes the bridge loses track of membership report packets (cb
      buffers are tied to a specific skb and not shared) and it ends up forwading
      join requests to the bridge interface.
      
      This can cause unexpected membership timeouts and intermitent/permanent loss
      of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]:
      
          A snooping switch should forward IGMP Membership Reports only to
          those ports where multicast routers are attached.
          [...]
          Sending membership reports to other hosts can result, for IGMPv1
          and IGMPv2, in unintentionally preventing a host from joining a
          specific multicast group.
      Signed-off-by: NFernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
      Tested-by: NHayato Kakuta <kakuta.hayato@oss.ntt.co.jp>
      Signed-off-by: NDavid S. Miller <davem@conan.davemloft.net>
      62b2bcb4
  3. 07 6月, 2011 1 次提交
    • A
      bridge: provide a cow_metrics method for fake_ops · 6407d74c
      Alexander Holler 提交于
      Like in commit 0972ddb2 (provide cow_metrics() methods to blackhole
      dst_ops), we must provide a cow_metrics for bridges fake_dst_ops as
      well.
      
      This fixes a regression coming from commits 62fa8a84 (net: Implement
      read-only protection and COW'ing of metrics.) and 33eb9873 (bridge:
      initialize fake_rtable metrics)
      
      ip link set mybridge mtu 1234
      -->
      [  136.546243] Pid: 8415, comm: ip Tainted: P 
      2.6.39.1-00006-g40545b7 #103 ASUSTeK Computer Inc.         V1Sn 
              /V1Sn
      [  136.546256] EIP: 0060:[<00000000>] EFLAGS: 00010202 CPU: 0
      [  136.546268] EIP is at 0x0
      [  136.546273] EAX: f14a389c EBX: 000005d4 ECX: f80d32c0 EDX: f80d1da1
      [  136.546279] ESI: f14a3000 EDI: f255bf10 EBP: f15c3b54 ESP: f15c3b48
      [  136.546285]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      [  136.546293] Process ip (pid: 8415, ti=f15c2000 task=f4741f80 
      task.ti=f15c2000)
      [  136.546297] Stack:
      [  136.546301]  f80c658f f14a3000 ffffffed f15c3b64 c12cb9c8 f80d1b80 
      ffffffa1 f15c3bbc
      [  136.546315]  c12da347 c12d9c7d 00000000 f7670b00 00000000 f80d1b80 
      ffffffa6 f15c3be4
      [  136.546329]  00000004 f14a3000 f255bf20 00000008 f15c3bbc c11d6cae 
      00000000 00000000
      [  136.546343] Call Trace:
      [  136.546359]  [<f80c658f>] ? br_change_mtu+0x5f/0x80 [bridge]
      [  136.546372]  [<c12cb9c8>] dev_set_mtu+0x38/0x80
      [  136.546381]  [<c12da347>] do_setlink+0x1a7/0x860
      [  136.546390]  [<c12d9c7d>] ? rtnl_fill_ifinfo+0x9bd/0xc70
      [  136.546400]  [<c11d6cae>] ? nla_parse+0x6e/0xb0
      [  136.546409]  [<c12db931>] rtnl_newlink+0x361/0x510
      [  136.546420]  [<c1023240>] ? vmalloc_sync_all+0x100/0x100
      [  136.546429]  [<c1362762>] ? error_code+0x5a/0x60
      [  136.546438]  [<c12db5d0>] ? rtnl_configure_link+0x80/0x80
      [  136.546446]  [<c12db27a>] rtnetlink_rcv_msg+0xfa/0x210
      [  136.546454]  [<c12db180>] ? __rtnl_unlock+0x20/0x20
      [  136.546463]  [<c12ee0fe>] netlink_rcv_skb+0x8e/0xb0
      [  136.546471]  [<c12daf1c>] rtnetlink_rcv+0x1c/0x30
      [  136.546479]  [<c12edafa>] netlink_unicast+0x23a/0x280
      [  136.546487]  [<c12ede6b>] netlink_sendmsg+0x26b/0x2f0
      [  136.546497]  [<c12bb828>] sock_sendmsg+0xc8/0x100
      [  136.546508]  [<c10adf61>] ? __alloc_pages_nodemask+0xe1/0x750
      [  136.546517]  [<c11d0602>] ? _copy_from_user+0x42/0x60
      [  136.546525]  [<c12c5e4c>] ? verify_iovec+0x4c/0xc0
      [  136.546534]  [<c12bd805>] sys_sendmsg+0x1c5/0x200
      [  136.546542]  [<c10c2150>] ? __do_fault+0x310/0x410
      [  136.546549]  [<c10c2c46>] ? do_wp_page+0x1d6/0x6b0
      [  136.546557]  [<c10c47d1>] ? handle_pte_fault+0xe1/0x720
      [  136.546565]  [<c12bd1af>] ? sys_getsockname+0x7f/0x90
      [  136.546574]  [<c10c4ec1>] ? handle_mm_fault+0xb1/0x180
      [  136.546582]  [<c1023240>] ? vmalloc_sync_all+0x100/0x100
      [  136.546589]  [<c10233b3>] ? do_page_fault+0x173/0x3d0
      [  136.546596]  [<c12bd87b>] ? sys_recvmsg+0x3b/0x60
      [  136.546605]  [<c12bdd83>] sys_socketcall+0x293/0x2d0
      [  136.546614]  [<c13629d0>] sysenter_do_call+0x12/0x26
      [  136.546619] Code:  Bad EIP value.
      [  136.546627] EIP: [<00000000>] 0x0 SS:ESP 0068:f15c3b48
      [  136.546645] CR2: 0000000000000000
      [  136.546652] ---[ end trace 6909b560e78934fa ]---
      Signed-off-by: NAlexander Holler <holler@ahsoftware.de>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6407d74c
  4. 27 5月, 2011 1 次提交
  5. 25 5月, 2011 1 次提交
  6. 23 5月, 2011 2 次提交
  7. 15 5月, 2011 1 次提交
  8. 14 5月, 2011 1 次提交
  9. 10 5月, 2011 2 次提交
  10. 03 5月, 2011 1 次提交
    • E
      net: dont hold rtnl mutex during netlink dump callbacks · e67f88dd
      Eric Dumazet 提交于
      Four years ago, Patrick made a change to hold rtnl mutex during netlink
      dump callbacks.
      
      I believe it was a wrong move. This slows down concurrent dumps, making
      good old /proc/net/ files faster than rtnetlink in some situations.
      
      This occurred to me because one "ip link show dev ..." was _very_ slow
      on a workload adding/removing network devices in background.
      
      All dump callbacks are able to use RCU locking now, so this patch does
      roughly a revert of commits :
      
      1c2d670f : [RTNETLINK]: Hold rtnl_mutex during netlink dump callbacks
      6313c1e0 : [RTNETLINK]: Remove unnecessary locking in dump callbacks
      
      This let writers fight for rtnl mutex and readers going full speed.
      
      It also takes care of phonet : phonet_route_get() is now called from rcu
      read section. I renamed it to phonet_route_get_rcu()
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Remi Denis-Courmont <remi.denis-courmont@nokia.com>
      Acked-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e67f88dd
  11. 30 4月, 2011 1 次提交
  12. 29 4月, 2011 1 次提交
  13. 23 4月, 2011 1 次提交
  14. 22 4月, 2011 1 次提交
  15. 21 4月, 2011 2 次提交
  16. 18 4月, 2011 1 次提交
  17. 13 4月, 2011 1 次提交
  18. 05 4月, 2011 7 次提交
  19. 31 3月, 2011 1 次提交
  20. 30 3月, 2011 2 次提交
  21. 28 3月, 2011 1 次提交
  22. 23 3月, 2011 1 次提交
  23. 19 3月, 2011 1 次提交
  24. 17 3月, 2011 1 次提交
  25. 15 3月, 2011 2 次提交
  26. 13 3月, 2011 1 次提交
  27. 11 3月, 2011 1 次提交
  28. 03 3月, 2011 1 次提交