1. 23 8月, 2011 1 次提交
  2. 11 8月, 2011 1 次提交
  3. 10 8月, 2011 1 次提交
  4. 27 7月, 2011 1 次提交
  5. 23 7月, 2011 5 次提交
  6. 21 7月, 2011 1 次提交
  7. 18 7月, 2011 3 次提交
  8. 14 7月, 2011 1 次提交
    • D
      net: Embed hh_cache inside of struct neighbour. · f6b72b62
      David S. Miller 提交于
      Now that there is a one-to-one correspondance between neighbour
      and hh_cache entries, we no longer need:
      
      1) dynamic allocation
      2) attachment to dst->hh
      3) refcounting
      
      Initialization of the hh_cache entry is indicated by hh_len
      being non-zero, and such initialization is always done with
      the neighbour's lock held as a writer.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6b72b62
  9. 06 7月, 2011 1 次提交
  10. 25 6月, 2011 1 次提交
    • H
      bridge: Only flood unregistered groups to routers · bd4265fe
      Herbert Xu 提交于
      The bridge currently floods packets to groups that we have never
      seen before to all ports.  This is not required by RFC4541 and
      in fact it is not desirable in environment where traffic to
      unregistered group is always present.
      
      This patch changes the behaviour so that we only send traffic
      to unregistered groups to ports marked as routers.
      
      The user can always force flooding behaviour to any given port
      by marking it as a router.
      
      Note that this change does not apply to traffic to 224.0.0.X
      as traffic to those groups must always be flooded to all ports.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd4265fe
  11. 20 6月, 2011 1 次提交
  12. 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
  13. 10 6月, 2011 1 次提交
    • G
      rtnetlink: Compute and store minimum ifinfo dump size · c7ac8679
      Greg Rose 提交于
      The message size allocated for rtnl ifinfo dumps was limited to
      a single page.  This is not enough for additional interface info
      available with devices that support SR-IOV and caused a bug in
      which VF info would not be displayed if more than approximately
      40 VFs were created per interface.
      
      Implement a new function pointer for the rtnl_register service that will
      calculate the amount of data required for the ifinfo dump and allocate
      enough data to satisfy the request.
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c7ac8679
  14. 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
  15. 27 5月, 2011 1 次提交
  16. 25 5月, 2011 1 次提交
  17. 23 5月, 2011 2 次提交
  18. 15 5月, 2011 1 次提交
  19. 14 5月, 2011 1 次提交
  20. 10 5月, 2011 2 次提交
  21. 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
  22. 30 4月, 2011 1 次提交
  23. 29 4月, 2011 1 次提交
  24. 23 4月, 2011 1 次提交
  25. 22 4月, 2011 1 次提交
  26. 21 4月, 2011 2 次提交
  27. 18 4月, 2011 1 次提交
  28. 13 4月, 2011 1 次提交
  29. 05 4月, 2011 2 次提交
    • S
      bridge: range check STP parameters · 14f98f25
      stephen hemminger 提交于
      Apply restrictions on STP parameters based 802.1D 1998 standard.
         * Fixes missing locking in set path cost ioctl
         * Uses common code for both ioctl and sysfs
      
      This is based on an earlier patch Sasikanth V but with overhaul.
      
      Note:
      1. It does NOT enforce the restriction on the relationship max_age and
         forward delay or hello time because in existing implementation these are
         set as independant operations.
      
      2. If STP is disabled, there is no restriction on forward delay
      
      3. No restriction on holding time because users use Linux code to act
         as hub or be sticky.
      
      4. Although standard allow 0-255, Linux only allows 0-63 for port priority
         because more bits are reserved for port number.
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      14f98f25
    • S
      bridge: allow creating bridge devices with netlink · bb900b27
      stephen hemminger 提交于
      Add netlink device ops to allow creating bridge device via netlink.
      This works in a manner similar to vlan, macvlan and bonding.
      
      Example:
        # ip link add link dev br0 type bridge
        # ip link del dev br0
      
      The change required rearranging initializtion code to deal with
      being called by create link. Most of the initialization happens
      in br_dev_setup, but allocation of stats is done in ndo_init callback
      to deal with allocation failure. Sysfs setup has to wait until
      after the network device kobject is registered.
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb900b27