drivers/net/vmxnet3/vmxnet3_ethtool.c | 3 ++ net/bridge/br_device.c | 4 +++ net/bridge/br_fdb.c | 15 +++++++---- net/bridge/br_if.c | 13 +++++----- net/bridge/br_netfilter.c | 13 +++++----- net/bridge/br_netlink.c | 10 ++++--- net/bridge/br_notify.c | 6 ++-- net/bridge/br_private.h | 17 ++++++++++--- net/bridge/br_stp.c | 43 +++++++++++++++++++++------------- net/bridge/br_stp_bpdu.c | 8 +++--- net/bridge/br_stp_if.c | 12 +++++++-- net/bridge/br_stp_timer.c | 2 + net/bridge/netfilter/ebtables.c | 11 +++----- net/core/dev.c | 1 14 files changed, 100 insertions(+), 58 deletions(-)
New commits: commit 99f21560fd693f0d2c5754a9105d6521e1dabd94 Author: stephen hemminger <[email protected]> Date: Thu Mar 24 13:24:01 2011 +0000 bridge: notify applications if address of bridge device changes The mac address of the bridge device may be changed when a new interface is added to the bridge. If this happens, then the bridge needs to call the network notifiers to tickle any other systems that care. Since bridge can be a module, this also means exporting the notifier function. Signed-off-by: Stephen Hemminger <[email protected]> Signed-off-by: David S. Miller <[email protected]> (cherry picked from commit edf947f10074fea27fdb1730524dca59355a1c40) commit e9a0b5ba6c8fedb5075cf9756a0fc47a80096949 Author: Stephen Hemminger <[email protected]> Date: Tue May 17 10:03:16 2011 -0700 bridge: add notification over netlink when STP changes state When STP changes state of interface need to send a new link message to reflect that change. Signed-off-by: Stephen Hemminger <[email protected]> commit 50420a9e3655371cbd30d030f053de18cbcd7cee Author: stephen hemminger <[email protected]> Date: Thu Mar 10 05:57:04 2011 +0000 bridge: skip forwarding delay if not using STP If Spanning Tree Protocol is not enabled, there is no good reason for the bridge code to wait for the forwarding delay period before enabling the link. The purpose of the forwarding delay is to allow STP to learn about other bridges before nominating itself. The only possible impact is that when starting up a new port the bridge may flood a packet now, where previously it might have seen traffic from the other host and preseeded the forwarding table. Includes change for local variable br already available in that func. Signed-off-by: Stephen Hemminger <[email protected]> Signed-off-by: David S. Miller <[email protected]> (cherry picked from commit a461c0297f2e80c78eaa03fc5141bf57a814ff4f) commit 1a8fd3aacd1affd98b6bc31d13738069c5b40988 Author: stephen hemminger <[email protected]> Date: Mon Mar 7 08:34:06 2011 +0000 bridge: control carrier based on ports online This makes the bridge device behave like a physical device. In earlier releases the bridge always asserted carrier. This changes the behavior so that bridge device carrier is on only if one or more ports are in the forwarding state. This should help IPv6 autoconfiguration, DHCP, and routing daemons. I did brief testing with Network and Virt manager and they seem fine, but since this changes behavior of bridge, it should wait until net-next (2.6.39). Signed-off-by: Stephen Hemminger <[email protected]> Reviewed-by: Nicolas de Pesloüan <[email protected]> Tested-By: Adam Majer <[email protected]> Signed-off-by: David S. Miller <[email protected]> (cherry picked from commit 1faa4356a3bd89ea11fb92752d897cff3a20ec0e) commit 4d303ee55717625531b1682eaad988771e69cc5c Author: Eric Dumazet <[email protected]> Date: Mon Nov 15 06:38:14 2010 +0000 bridge: add RCU annotations to bridge port lookup br_port_get() renamed to br_port_get_rtnl() to make clear RTNL is held. Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: Stephen Hemminger <[email protected]> Signed-off-by: David S. Miller <[email protected]> (cherry picked from commit ec1e5610c00c7f5bc530d2aadd47faa473b90a30) commit a78574f251130507694a8251fa3dc27b4ce810cd Author: stephen hemminger <[email protected]> Date: Mon Nov 15 06:38:13 2010 +0000 bridge: fix RCU races with bridge port The macro br_port_exists() is not enough protection when only RCU is being used. There is a tiny race where other CPU has cleared port handler hook, but is bridge port flag might still be set. Signed-off-by: Stephen Hemminger <[email protected]> Signed-off-by: David S. Miller <[email protected]> (cherry picked from commit b5ed54e94d324f17c97852296d61a143f01b227a) commit 131598dff663c0e836eac1d516dd48b5d50e8986 Author: Thomas Jarosch <[email protected]> Date: Mon May 16 18:28:15 2011 +0200 vmxnet3: Fix inconsistent LRO state after initialization During initialization of vmxnet3, the state of LRO gets out of sync with netdev->features. This leads to very poor TCP performance in a IP forwarding setup and is hitting many VMware users. Simplified call sequence: 1. vmxnet3_declare_features() initializes "adapter->lro" to true. 2. The kernel automatically disables LRO if IP forwarding is enabled, so vmxnet3_set_flags() gets called. This also updates netdev->features. 3. Now vmxnet3_setup_driver_shared() is called. "adapter->lro" is still set to true and LRO gets enabled again, even though netdev->features shows it's disabled. Fix it by updating "adapter->lro", too. The private vmxnet3 adapter flags are scheduled for removal in net-next, see commit a0d2730c9571aeba793cb5d3009094ee1d8fda35 "net: vmxnet3: convert to hw_features". Patch applies to 2.6.37 / 2.6.38 and 2.6.39-rc6. Please CC: comments. Signed-off-by: Thomas Jarosch <[email protected]> http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hf21560fd693f0d2c5754a9105d6521e1dabd94 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;héa0b5ba6c8fedb5075cf9756a0fc47a80096949 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hP420a9e3655371cbd30d030f053de18cbcd7cee http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h8fd3aacd1affd98b6bc31d13738069c5b40988 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;hM303ee55717625531b1682eaad988771e69cc5c http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h§8574f251130507694a8251fa3dc27b4ce810cd http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h1598dff663c0e836eac1d516dd48b5d50e8986
_______________________________________________ svn mailing list [email protected] http://mailman.vyatta.com/mailman/listinfo/svn
