1. 17 11月, 2011 3 次提交
  2. 14 11月, 2011 2 次提交
  3. 01 11月, 2011 3 次提交
  4. 19 10月, 2011 1 次提交
  5. 07 10月, 2011 2 次提交
    • S
      bridge: allow forwarding some link local frames · 515853cc
      stephen hemminger 提交于
      This is based on an earlier patch by Nick Carter with comments
      by David Lamparter but with some refinements. Thanks for their patience
      this is a confusing area with overlap of standards, user requirements,
      and compatibility with earlier releases.
      
      It adds a new sysfs attribute
         /sys/class/net/brX/bridge/group_fwd_mask
      that controls forwarding of frames with address of: 01-80-C2-00-00-0X
      The default setting has no forwarding to retain compatibility.
      
      One change from earlier releases is that forwarding of group
      addresses is not dependent on STP being enabled or disabled. This
      choice was made based on interpretation of tie 802.1 standards.
      I expect complaints will arise because of this, but better to follow
      the standard than continue acting incorrectly by default.
      
      The filtering mask is writeable, but only values that don't forward
      known control frames are allowed. It intentionally blocks attempts
      to filter control protocols. For example: writing a 8 allows
      forwarding 802.1X PAE addresses which is the most common request.
      Reported-by: NDavid Lamparter <equinox@diac24.net>
      Original-patch-by: NNick Carter <ncarter100@gmail.com>
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Tested-by: NBenjamin Poirier <benjamin.poirier@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      515853cc
    • S
      bridge: leave carrier on for empty bridge · b64b73d7
      stephen hemminger 提交于
      This resolves a regression seen by some users of bridging.
      Some users use the bridge like a dummy device.
      They expect to be able to put an IPv6 address on the device
      with no ports attached. Although there are better ways of doing
      this, there is no reason to not allow it.
      
      Note: the bridge still will reflect the state of ports in the
      bridge if there are any added.
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b64b73d7
  6. 04 10月, 2011 2 次提交
  7. 16 9月, 2011 2 次提交
    • J
      net: consolidate and fix ethtool_ops->get_settings calling · 4bc71cb9
      Jiri Pirko 提交于
      This patch does several things:
      - introduces __ethtool_get_settings which is called from ethtool code and
        from drivers as well. Put ASSERT_RTNL there.
      - dev_ethtool_get_settings() is replaced by __ethtool_get_settings()
      - changes calling in drivers so rtnl locking is respected. In
        iboe_get_rate was previously ->get_settings() called unlocked. This
        fixes it. Also prb_calc_retire_blk_tmo() in af_packet.c had the same
        problem. Also fixed by calling __dev_get_by_index() instead of
        dev_get_by_index() and holding rtnl_lock for both calls.
      - introduces rtnl_lock in bnx2fc_vport_create() and fcoe_vport_create()
        so bnx2fc_if_create() and fcoe_if_create() are called locked as they
        are from other places.
      - use __ethtool_get_settings() in bonding code
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      
      v2->v3:
      	-removed dev_ethtool_get_settings()
      	-added ASSERT_RTNL into __ethtool_get_settings()
      	-prb_calc_retire_blk_tmo - use __dev_get_by_index() and lock
      	 around it and __ethtool_get_settings() call
      v1->v2:
              add missing export_symbol
      Reviewed-by: Ben Hutchings <bhutchings@solarflare.com> [except FCoE bits]
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4bc71cb9
    • J
      br: remove redundant check and init · fa3df928
      Jiri Pirko 提交于
      Since these checks and initialization are done in
      dev_ethtool_get_settings called later on, remove this redundancy.
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      Acked-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fa3df928
  8. 25 8月, 2011 2 次提交
  9. 23 8月, 2011 1 次提交
  10. 18 8月, 2011 1 次提交
  11. 11 8月, 2011 1 次提交
  12. 10 8月, 2011 1 次提交
  13. 02 8月, 2011 1 次提交
  14. 29 7月, 2011 1 次提交
  15. 27 7月, 2011 1 次提交
  16. 23 7月, 2011 5 次提交
  17. 21 7月, 2011 1 次提交
  18. 18 7月, 2011 3 次提交
  19. 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
  20. 06 7月, 2011 1 次提交
  21. 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
  22. 20 6月, 2011 1 次提交
  23. 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
  24. 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