16 Jan, 2016
1 commit
-
After promisc mode management was introduced a bridge device could do
dev_set_promiscuity from its ndo_change_rx_flags() callback which in
turn can be called after the bridge's addr_list_lock has been taken
(e.g. by dev_uc_add). This causes a false positive lockdep splat because
the port interfaces' addr_list_lock is taken when br_manage_promisc()
runs after the bridge's addr list lock was already taken.
To remove the false positive introduce a custom bridge addr_list_lock
class and set it on bridge init.
A simple way to reproduce this is with the following:
$ brctl addbr br0
$ ip l add l br0 br0.100 type vlan id 100
$ ip l set br0 up
$ ip l set br0.100 up
$ echo 1 > /sys/class/net/br0/bridge/vlan_filtering
$ brctl addif br0 eth0
Splat:
[ 43.684325] =============================================
[ 43.684485] [ INFO: possible recursive locking detected ]
[ 43.684636] 4.4.0-rc8+ #54 Not tainted
[ 43.684755] ---------------------------------------------
[ 43.684906] brctl/1187 is trying to acquire lock:
[ 43.685047] (_xmit_ETHER){+.....}, at: [] dev_set_rx_mode+0x1e/0x40
[ 43.685460] but task is already holding lock:
[ 43.685618] (_xmit_ETHER){+.....}, at: [] dev_uc_add+0x27/0x80
[ 43.686015] other info that might help us debug this:
[ 43.686316] Possible unsafe locking scenario:[ 43.686743] CPU0
[ 43.686967] ----
[ 43.687197] lock(_xmit_ETHER);
[ 43.687544] lock(_xmit_ETHER);
[ 43.687886] *** DEADLOCK ***[ 43.688438] May be due to missing lock nesting notation
[ 43.688882] 2 locks held by brctl/1187:
[ 43.689134] #0: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x17/0x20
[ 43.689852] #1: (_xmit_ETHER){+.....}, at: [] dev_uc_add+0x27/0x80
[ 43.690575] stack backtrace:
[ 43.690970] CPU: 0 PID: 1187 Comm: brctl Not tainted 4.4.0-rc8+ #54
[ 43.691270] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.1-20150318_183358- 04/01/2014
[ 43.691770] ffffffff826a25c0 ffff8800369fb8e0 ffffffff81360ceb ffffffff826a25c0
[ 43.692425] ffff8800369fb9b8 ffffffff810d0466 ffff8800369fb968 ffffffff81537139
[ 43.693071] ffff88003a08c880 0000000000000000 00000000ffffffff 0000000002080020
[ 43.693709] Call Trace:
[ 43.693931] [] dump_stack+0x4b/0x70
[ 43.694199] [] __lock_acquire+0x1e46/0x1e90
[ 43.694483] [] ? netlink_broadcast_filtered+0x139/0x3e0
[ 43.694789] [] ? nlmsg_notify+0x5a/0xc0
[ 43.695064] [] lock_acquire+0xe5/0x1f0
[ 43.695340] [] ? dev_set_rx_mode+0x1e/0x40
[ 43.695623] [] _raw_spin_lock_bh+0x45/0x80
[ 43.695901] [] ? dev_set_rx_mode+0x1e/0x40
[ 43.696180] [] dev_set_rx_mode+0x1e/0x40
[ 43.696460] [] dev_set_promiscuity+0x3c/0x50
[ 43.696750] [] br_port_set_promisc+0x25/0x50 [bridge]
[ 43.697052] [] br_manage_promisc+0x8a/0xe0 [bridge]
[ 43.697348] [] br_dev_change_rx_flags+0x1e/0x20 [bridge]
[ 43.697655] [] __dev_set_promiscuity+0x132/0x1f0
[ 43.697943] [] __dev_set_rx_mode+0x82/0x90
[ 43.698223] [] dev_uc_add+0x5e/0x80
[ 43.698498] [] vlan_device_event+0x542/0x650 [8021q]
[ 43.698798] [] notifier_call_chain+0x5d/0x80
[ 43.699083] [] raw_notifier_call_chain+0x16/0x20
[ 43.699374] [] call_netdevice_notifiers_info+0x6e/0x80
[ 43.699678] [] call_netdevice_notifiers+0x16/0x20
[ 43.699973] [] br_add_if+0x47e/0x4c0 [bridge]
[ 43.700259] [] add_del_if+0x6e/0x80 [bridge]
[ 43.700548] [] br_dev_ioctl+0xaf/0xc0 [bridge]
[ 43.700836] [] dev_ifsioc+0x30c/0x3c0
[ 43.701106] [] dev_ioctl+0xf9/0x6f0
[ 43.701379] [] ? mntput_no_expire+0x5/0x450
[ 43.701665] [] ? mntput_no_expire+0xae/0x450
[ 43.701947] [] sock_do_ioctl+0x42/0x50
[ 43.702219] [] sock_ioctl+0x1e5/0x290
[ 43.702500] [] do_vfs_ioctl+0x2cb/0x5c0
[ 43.702771] [] SyS_ioctl+0x79/0x90
[ 43.703033] [] entry_SYSCALL_64_fastpath+0x16/0x7aCC: Vlad Yasevich
CC: Stephen Hemminger
CC: Bridge list
CC: Andy Gospodarek
CC: Roopa Prabhu
Fixes: 2796d0c648c9 ("bridge: Automatically manage port promiscuous mode.")
Reported-by: Andy Gospodarek
Signed-off-by: Nikolay Aleksandrov
Signed-off-by: David S. Miller
13 Oct, 2015
1 commit
-
The bridge and port's vlgrp member is already used in RCU way, currently
we rely on the fact that it cannot disappear while the port exists but
that is error-prone and we might miss places with improper locking
(either RCU or RTNL must be held to walk the vlan_list). So make it
official and use RCU for vlgrp to catch offenders. Introduce proper vlgrp
accessors and use them consistently throughout the code.Signed-off-by: Nikolay Aleksandrov
Reviewed-by: Ido Schimmel
Signed-off-by: David S. Miller
02 Oct, 2015
1 commit
-
One obvious way to converge more code (which was also used by the
previous vlan code) is to move pvid inside net_bridge_vlan_group. This
allows us to simplify some and remove other port-specific functions.
Also gives us the ability to simply pass the vlan group and use all of the
contained information.Signed-off-by: Nikolay Aleksandrov
Signed-off-by: David S. Miller
30 Sep, 2015
1 commit
-
This patch changes the bridge vlan implementation to use rhashtables
instead of bitmaps. The main motivation behind this change is that we
need extensible per-vlan structures (both per-port and global) so more
advanced features can be introduced and the vlan support can be
extended. I've tried to break this up but the moment net_port_vlans is
changed and the whole API goes away, thus this is a larger patch.
A few short goals of this patch are:
- Extensible per-vlan structs stored in rhashtables and a sorted list
- Keep user-visible behaviour (compressed vlans etc)
- Keep fastpath ingress/egress logic the same (optimizations to come
later)Here's a brief list of some of the new features we'd like to introduce:
- per-vlan counters
- vlan ingress/egress mapping
- per-vlan igmp configuration
- vlan priorities
- avoid fdb entries replication (e.g. local fdb scaling issues)The structure is kept single for both global and per-port entries so to
avoid code duplication where possible and also because we'll soon introduce
"port0 / aka bridge as port" which should simplify things further
(thanks to Vlad for the suggestion!).Now we have per-vlan global rhashtable (bridge-wide) and per-vlan port
rhashtable, if an entry is added to a port it'll get a pointer to its
global context so it can be quickly accessed later. There's also a
sorted vlan list which is used for stable walks and some user-visible
behaviour such as the vlan ranges, also for error paths.
VLANs are stored in a "vlan group" which currently contains the
rhashtable, sorted vlan list and the number of "real" vlan entries.
A good side-effect of this change is that it resembles how hw keeps
per-vlan data.
One important note after this change is that if a VLAN is being looked up
in the bridge's rhashtable for filtering purposes (or to check if it's an
existing usable entry, not just a global context) then the new helper
br_vlan_should_use() needs to be used if the vlan is found. In case the
lookup is done only with a port's vlan group, then this check can be
skipped.Things tested so far:
- basic vlan ingress/egress
- pvids
- untagged vlans
- undef CONFIG_BRIDGE_VLAN_FILTERING
- adding/deleting vlans in different scenarios (with/without global ctx,
while transmitting traffic, in ranges etc)
- loading/removing the module while having/adding/deleting vlans
- extracting bridge vlan information (user ABI), compressed requests
- adding/deleting fdbs on vlans
- bridge mac change, promisc mode
- default pvid change
- kmemleak ON during the whole timeSigned-off-by: Nikolay Aleksandrov
Signed-off-by: David S. Miller
24 Sep, 2015
1 commit
-
Signed-off-by: Scott Feldman
Acked-by: Jiri Pirko
Signed-off-by: David S. Miller
19 Aug, 2015
1 commit
-
Signed-off-by: Phil Sutter
Cc: Stephen Hemminger
Signed-off-by: David S. Miller
04 Aug, 2015
1 commit
-
Bridge devices don't need to segment multiple tagged packets since thier
ports can segment them.Signed-off-by: Toshiaki Makita
Signed-off-by: David S. Miller
10 Mar, 2015
2 commits
-
e5de75b ("netfilter: bridge: move DNAT helper to br_netfilter") results
in the following link problem:net/bridge/br_device.c:29: undefined reference to `br_nf_prerouting_finish_bridge`
Moreover it creates a hard dependency between br_netfilter and the
bridge core, which is what we've been trying to avoid so far.Resolve this problem by using a hook structure so we reduce #ifdef
pollution and keep bridge netfilter specific code under br_netfilter.c
which was the original intention.Reported-by: Simon Horman
Signed-off-by: Pablo Neira Ayuso -
Only one caller, there is no need to keep this in a header.
Move it to br_netfilter.c where this belongs to.Based on patch from Florian Westphal.
Signed-off-by: Pablo Neira Ayuso
06 Oct, 2014
1 commit
-
Currently when vlan filtering is turned on on the bridge, the bridge
will drop all traffic untill the user configures the filter. This
isn't very nice for ports that don't care about vlans and just
want untagged traffic.A concept of a default_pvid was recently introduced. This patch
adds filtering support for default_pvid. Now, ports that don't
care about vlans and don't define there own filter will belong
to the VLAN of the default_pvid and continue to receive untagged
traffic.This filtering can be disabled by setting default_pvid to 0.
Signed-off-by: Vladislav Yasevich
Signed-off-by: David S. Miller
27 Sep, 2014
1 commit
-
Jesper reported that br_netfilter always registers the hooks since
this is part of the bridge core. This harms performance for people that
don't need this.This patch modularizes br_netfilter so it can be rmmod'ed, thus,
the hooks can be unregistered. I think the bridge netfilter should have
been a separated module since the beginning, Patrick agreed on that.Note that this is breaking compatibility for users that expect that
bridge netfilter is going to be available after explicitly 'modprobe
bridge' or via automatic load through brctl.However, the damage can be easily undone by modprobing br_netfilter.
The bridge core also spots a message to provide a clue to people that
didn't notice that this has been deprecated.On top of that, the plan is that nftables will not rely on this software
layer, but integrate the connection tracking into the bridge layer to
enable stateful filtering and NAT, which is was bridge netfilter users
seem to require.This patch still keeps the fake_dst_ops in the bridge core, since this
is required by when the bridge port is initialized. So we can safely
modprobe/rmmod br_netfilter anytime.Signed-off-by: Pablo Neira Ayuso
Acked-by: Florian Westphal
12 Jun, 2014
3 commits
-
If a bridge is an 802.1ad bridge, it must forward another bridge group
addresses (the Nearest Customer Bridge group addresses).
(For details, see IEEE 802.1Q-2011 8.6.3.)As user might not want group_fwd_mask to be modified by enabling 802.1ad,
introduce a new mask, group_fwd_mask_required, which indicates addresses
the bridge wants to forward. This will be set by enabling 802.1ad.Signed-off-by: Toshiaki Makita
Signed-off-by: David S. Miller -
This enables a bridge to have vlan protocol informantion and allows vlan
tag manipulation (retrieve, insert and remove tags) according to the vlan
protocol.Signed-off-by: Toshiaki Makita
Signed-off-by: David S. Miller -
Bridge device doesn't need to embed S-tag into skb->data.
Signed-off-by: Toshiaki Makita
Signed-off-by: David S. Miller
17 May, 2014
1 commit
-
There exist configurations where the administrator or another management
entity has the foreknowledge of all the mac addresses of end systems
that are being bridged together.In these environments, the administrator can statically configure known
addresses in the bridge FDB and disable flooding and learning on ports.
This makes it possible to turn off promiscuous mode on the interfaces
connected to the bridge.Here is why disabling flooding and learning allows us to control
promiscuity:
Consider port X. All traffic coming into this port from outside the
bridge (ingress) will be either forwarded through other ports of the
bridge (egress) or dropped. Forwarding (egress) is defined by FDB
entries and by flooding in the event that no FDB entry exists.
In the event that flooding is disabled, only FDB entries define
the egress. Once learning is disabled, only static FDB entries
provided by a management entity define the egress. If we provide
information from these static FDBs to the ingress port X, then we'll
be able to accept all traffic that can be successfully forwarded and
drop all the other traffic sooner without spending CPU cycles to
process it.
Another way to define the above is as following equations:
ingress = egress + drop
expanding egress
ingress = static FDB + learned FDB + flooding + drop
disabling flooding and learning we a left with
ingress = static FDB + dropBy adding addresses from the static FDB entries to the MAC address
filter of an ingress port X, we fully define what the bridge can
process without dropping and can thus turn off promiscuous mode,
thus dropping packets sooner.There have been suggestions that we may want to allow learning
and update the filters with learned addresses as well. This
would require mac-level authentication similar to 802.1x to
prevent attacks against the hw filters as they are limited
resource.Additionally, if the user places the bridge device in promiscuous mode,
all ports are placed in promiscuous mode regardless of the changes
to flooding and learning.Since the above functionality depends on full static configuration,
we have also require that vlan filtering be enabled to take
advantage of this. The reason is that the bridge has to be
able to receive and process VLAN-tagged frames and the there
are only 2 ways to accomplish this right now: promiscuous mode
or vlan filtering.Suggested-by: Michael S. Tsirkin
Acked-by: Michael S. Tsirkin
Signed-off-by: Vlad Yasevich
Signed-off-by: David S. Miller
14 May, 2014
1 commit
-
net: get rid of SET_ETHTOOL_OPS
Dave Miller mentioned he'd like to see SET_ETHTOOL_OPS gone.
This does that.Mostly done via coccinelle script:
@@
struct ethtool_ops *ops;
struct net_device *dev;
@@
- SET_ETHTOOL_OPS(dev, ops);
+ dev->ethtool_ops = ops;Compile tested only, but I'd seriously wonder if this broke anything.
Suggested-by: Dave Miller
Signed-off-by: Wilfried Klaebe
Acked-by: Felipe Balbi
Signed-off-by: David S. Miller
30 Mar, 2014
2 commits
-
Conflicts:
drivers/net/ethernet/marvell/mvneta.cThe mvneta.c conflict is a case of overlapping changes,
a conversion to devm_ioremap_resource() vs. a conversion
to netdev_alloc_pcpu_stats.Signed-off-by: David S. Miller
-
The gfp parameter was added in:
commit 47be03a28cc6c80e3aa2b3e8ed6d960ff0c5c0af
Author: Amerigo Wang
Date: Fri Aug 10 01:24:37 2012 +0000netpoll: use GFP_ATOMIC in slave_enable_netpoll() and __netpoll_setup()
slave_enable_netpoll() and __netpoll_setup() may be called
with read_lock() held, so should use GFP_ATOMIC to allocate
memory. Eric suggested to pass gfp flags to __netpoll_setup().Cc: Eric Dumazet
Cc: "David S. Miller"
Reported-by: Dan Carpenter
Signed-off-by: Eric Dumazet
Signed-off-by: Cong Wang
Signed-off-by: David S. MillerThe reason for the gfp parameter was removed in:
commit c4cdef9b7183159c23c7302aaf270d64c549f557
Author: dingtianhong
Date: Tue Jul 23 15:25:27 2013 +0800bonding: don't call slave_xxx_netpoll under spinlocks
The slave_xxx_netpoll will call synchronize_rcu_bh(),
so the function may schedule and sleep, it should't be
called under spinlocks.bond_netpoll_setup() and bond_netpoll_cleanup() are always
protected by rtnl lock, it is no need to take the read lock,
as the slave list couldn't be changed outside rtnl lock.Signed-off-by: Ding Tianhong
Cc: Jay Vosburgh
Cc: Andy Gospodarek
Signed-off-by: David S. MillerNothing else that calls __netpoll_setup or ndo_netpoll_setup
requires a gfp paramter, so remove the gfp parameter from both
of these functions making the code clearer.Signed-off-by: "Eric W. Biederman"
Signed-off-by: David S. Miller
29 Mar, 2014
1 commit
-
Bridge vlan code (br_vlan_get_tag()) assumes that all frames have vlan_tci
if they are tagged, but if vlan tx offload is manually disabled on bridge
device and frames are sent from vlan device on the bridge device, the tags
are embedded in skb->data and they break this assumption.
Extract embedded vlan tags and move them to vlan_tci at ingress.Signed-off-by: Toshiaki Makita
Acked-by: Vlad Yasevich
Signed-off-by: David S. Miller
15 Mar, 2014
1 commit
-
Replace the bh safe variant with the hard irq safe variant.
We need a hard irq safe variant to deal with netpoll transmitting
packets from hard irq context, and we need it in most if not all of
the places using the bh safe variant.Except on 32bit uni-processor the code is exactly the same so don't
bother with a bh variant, just have a hard irq safe variant that
everyone can use.Signed-off-by: "Eric W. Biederman"
Signed-off-by: David S. Miller
25 Feb, 2014
1 commit
-
Convert the more obvious uses of memcpy to ether_addr_copy.
There are still uses of memcpy that could be converted but
these addresses are __aligned(2).Convert a couple uses of 6 in gr_private.h to ETH_ALEN.
Signed-off-by: Joe Perches
Signed-off-by: David S. Miller
15 Feb, 2014
1 commit
-
There are many drivers calling alloc_percpu() to allocate pcpu stats
and then initializing ->syncp. So just introduce a helper function for them.Cc: David S. Miller
Signed-off-by: Cong Wang
Signed-off-by: David S. Miller
11 Feb, 2014
2 commits
-
Vlan code may need fdb change when changing mac address of bridge device
even if it is caused by the mac address changing of a bridge port.Example configuration:
ip link set eth0 address 12:34:56:78:90:ab
ip link set eth1 address aa:bb:cc:dd:ee:ff
brctl addif br0 eth0
brctl addif br0 eth1 # br0 will have mac address 12:34:56:78:90:ab
bridge vlan add dev br0 vid 10 self
bridge vlan add dev eth0 vid 10
We will have fdb entry such that f->dst == NULL, f->vlan_id == 10 and
f->addr == 12:34:56:78:90:ab at this time.
Next, change the mac address of eth0 to greater value.
ip link set eth0 address ee:ff:12:34:56:78
Then, mac address of br0 will be recalculated and set to aa:bb:cc:dd:ee:ff.
However, an entry aa:bb:cc:dd:ee:ff will not be created and we will be not
able to communicate using br0 on vlan 10.Address this issue by deleting and adding local entries whenever
changing the mac address of the bridge device.If there already exists an entry that has the same address, for example,
in case that br_fdb_changeaddr() has already inserted it,
br_fdb_change_mac_address() will simply fail to insert it and no
duplicated entry will be made, as it was.This approach also needs br_add_if() to call br_fdb_insert() before
br_stp_recalculate_bridge_id() so that we don't create an entry whose
dst == NULL in this function to preserve previous behavior.Note that this is a slight change in behavior where the bridge device can
receive the traffic to the new address before calling
br_stp_recalculate_bridge_id() in br_add_if().
However, it is not a problem because we have already the address on the
new port and such a way to insert new one before recalculating bridge id
is taken in br_device_event() as well.Signed-off-by: Toshiaki Makita
Acked-by: Vlad Yasevich
Signed-off-by: David S. Miller -
We have been always failed to delete the old entry at
br_fdb_change_mac_address() because br_set_mac_address() updates
dev->dev_addr before calling br_fdb_change_mac_address() and
br_fdb_change_mac_address() uses dev->dev_addr to find the old entry.That update of dev_addr is completely unnecessary because the same work
is done in br_stp_change_bridge_id() which is called right away after
calling br_fdb_change_mac_address().Signed-off-by: Toshiaki Makita
Acked-by: Vlad Yasevich
Signed-off-by: David S. Miller
07 Feb, 2014
1 commit
-
Commit 93d8bf9fb8f3 ("bridge: cleanup netpoll code") introduced
a check in br_netpoll_enable(), but this check is incorrect for
br_netpoll_setup(). This patch moves the code after the check
into __br_netpoll_enable() and calls it in br_netpoll_setup().
For br_add_if(), the check is still needed.Fixes: 93d8bf9fb8f3 ("bridge: cleanup netpoll code")
Cc: Toshiaki Makita
Cc: Stephen Hemminger
Cc: David S. Miller
Signed-off-by: Cong Wang
Signed-off-by: Cong Wang
Acked-by: Toshiaki Makita
Tested-by: Toshiaki Makita
Signed-off-by: David S. Miller
05 Jan, 2014
1 commit
-
They are same, so unify them as one, pcpu_sw_netstats.
Define pcpu_sw_netstat in netdevice.h, remove pcpu_tstats
from if_tunnel and remove br_cpu_netstats from br_private.hCc: Cong Wang
Cc: Stephen Hemminger
Signed-off-by: Li RongQing
Signed-off-by: David S. Miller
14 Nov, 2013
1 commit
-
Pull core locking changes from Ingo Molnar:
"The biggest changes:- add lockdep support for seqcount/seqlocks structures, this
unearthed both bugs and required extra annotation.- move the various kernel locking primitives to the new
kernel/locking/ directory"* 'core-locking-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (21 commits)
block: Use u64_stats_init() to initialize seqcounts
locking/lockdep: Mark __lockdep_count_forward_deps() as static
lockdep/proc: Fix lock-time avg computation
locking/doc: Update references to kernel/mutex.c
ipv6: Fix possible ipv6 seqlock deadlock
cpuset: Fix potential deadlock w/ set_mems_allowed
seqcount: Add lockdep functionality to seqcount/seqlock structures
net: Explicitly initialize u64_stats_sync structures for lockdep
locking: Move the percpu-rwsem code to kernel/locking/
locking: Move the lglocks code to kernel/locking/
locking: Move the rwsem code to kernel/locking/
locking: Move the rtmutex code to kernel/locking/
locking: Move the semaphore core to kernel/locking/
locking: Move the spinlock code to kernel/locking/
locking: Move the lockdep code to kernel/locking/
locking: Move the mutex code to kernel/locking/
hung_task debugging: Add tracepoint to report the hang
x86/locking/kconfig: Update paravirt spinlock Kconfig description
lockstat: Report avg wait and hold times
lockdep, x86/alternatives: Drop ancient lockdep fixup message
...
06 Nov, 2013
1 commit
-
In order to enable lockdep on seqcount/seqlock structures, we
must explicitly initialize any locks.The u64_stats_sync structure, uses a seqcount, and thus we need
to introduce a u64_stats_init() function and use it to initialize
the structure.This unfortunately adds a lot of fairly trivial initialization code
to a number of drivers. But the benefit of ensuring correctness makes
this worth while.Because these changes are required for lockdep to be enabled, and the
changes are quite trivial, I've not yet split this patch out into 30-some
separate patches, as I figured it would be better to get the various
maintainers thoughts on how to best merge this change along with
the seqcount lockdep enablement.Feedback would be appreciated!
Signed-off-by: John Stultz
Acked-by: Julian Anastasov
Signed-off-by: Peter Zijlstra
Cc: Alexey Kuznetsov
Cc: "David S. Miller"
Cc: Eric Dumazet
Cc: Hideaki YOSHIFUJI
Cc: James Morris
Cc: Jesse Gross
Cc: Mathieu Desnoyers
Cc: "Michael S. Tsirkin"
Cc: Mirko Lindner
Cc: Patrick McHardy
Cc: Roger Luethi
Cc: Rusty Russell
Cc: Simon Horman
Cc: Stephen Hemminger
Cc: Steven Rostedt
Cc: Thomas Petazzoni
Cc: Wensong Zhang
Cc: netdev@vger.kernel.org
Link: http://lkml.kernel.org/r/1381186321-4906-2-git-send-email-john.stultz@linaro.org
Signed-off-by: Ingo Molnar
30 Oct, 2013
1 commit
-
Currently multicast code attempts to extrace the vlan id from
the skb even when vlan filtering is disabled. This can lead
to mdb entries being created with the wrong vlan id.
Pass the already extracted vlan id to the multicast
filtering code to make the correct id is used in
creation as well as lookup.Signed-off-by: Vlad Yasevich
Acked-by: Toshiaki Makita
Signed-off-by: David S. Miller
06 Sep, 2013
1 commit
-
Conflicts:
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
net/bridge/br_multicast.c
net/ipv6/sit.cThe conflicts were minor:
1) sit.c changes overlap with change to ip_tunnel_xmit() signature.
2) br_multicast.c had an overlap between computing max_delay using
msecs_to_jiffies and turning MLDV2_MRC() into an inline function
with a name using lowercase instead of uppercase letters.3) stmmac had two overlapping changes, one which conditionally allocated
and hooked up a dma_cfg based upon the presence of the pbl OF property,
and another one handling store-and-forward DMA made. The latter of
which should not go into the new of_find_property() basic block.Signed-off-by: David S. Miller
31 Aug, 2013
1 commit
-
Currently we would still potentially suffer multicast packet loss if there
is just either an IGMP or an MLD querier: For the former case, we would
possibly drop IPv6 multicast packets, for the latter IPv4 ones. This is
because we are currently assuming that if either an IGMP or MLD querier
is present that the other one is present, too.This patch makes the behaviour and fix added in
"bridge: disable snooping if there is no querier" (b00589af3b04)
to also work if there is either just an IGMP or an MLD querier on the
link: It refines the deactivation of the snooping to be protocol
specific by using separate timers for the snooped IGMP and MLD queries
as well as separate timers for our internal IGMP and MLD queriers.Signed-off-by: Linus Lüssing
Signed-off-by: David S. Miller
04 Aug, 2013
1 commit
-
Merge net into net-next to setup some infrastructure Eric
Dumazet needs for usbnet changes.Signed-off-by: David S. Miller
01 Aug, 2013
1 commit
-
If there is no querier on a link then we won't get periodic reports and
therefore won't be able to learn about multicast listeners behind ports,
potentially leading to lost multicast packets, especially for multicast
listeners that joined before the creation of the bridge.These lost multicast packets can appear since c5c23260594
("bridge: Add multicast_querier toggle and disable queries by default")
in particular.With this patch we are flooding multicast packets if our querier is
disabled and if we didn't detect any other querier.A grace period of the Maximum Response Delay of the querier is added to
give multicast responses enough time to arrive and to be learned from
before disabling the flooding behaviour again.Signed-off-by: Linus Lüssing
Signed-off-by: David S. Miller
27 Jul, 2013
1 commit
-
This started out with fixing a sparse warning, then I realized that
the wrapper function br_netpoll_info could just be collapsed away
by rolling it into the enable code.Also, eliminate unnecessary goto's
Signed-off-by: Stephen Hemminger
Reviewed-by: Jiri Pirko
Acked-by: Neil Horman
Signed-off-by: David S. Miller
11 Jun, 2013
1 commit
-
Add a flag to control flood of unicast traffic. By default, flood is
on and the bridge will flood unicast traffic if it doesn't know
the destination. When the flag is turned off, unicast traffic
without an FDB will not be forwarded to the specified port.Signed-off-by: Vlad Yasevich
Reviewed-by: Michael S. Tsirkin
Signed-off-by: David S. Miller
24 May, 2013
1 commit
-
When vlan device is configured on top of the brige, it does
not support any offload capabilities because the bridge
device does not initiliaze vlan_fatures. Set vlan_fatures to
be equivalent to hw_fatures.Signed-off-by: Vlad Yasevich
Signed-off-by: David S. Miller
20 Apr, 2013
1 commit
-
Rename the hardware VLAN acceleration features to include "CTAG" to indicate
that they only support CTAGs. Follow up patches will introduce 802.1ad
server provider tagging (STAGs) and require the distinction for hardware not
supporting acclerating both.Signed-off-by: Patrick McHardy
Signed-off-by: David S. Miller
08 Mar, 2013
1 commit
-
Obviously, vid should be considered when searching for multicast
group.Cc: Vlad Yasevich
Cc: Stephen Hemminger
Cc: "David S. Miller"
Signed-off-by: Cong Wang
Acked-by: Vlad Yasevich
Signed-off-by: David S. Miller
14 Feb, 2013
2 commits
-
This patch adds vlan to unicast fdb entries that are created for
learned addresses (not the manually configured ones). It adds
vlan id into the hash mix and uses vlan as an addditional parameter
for an entry match.Signed-off-by: Vlad Yasevich
Signed-off-by: David S. Miller -
At ingress, any untagged traffic is assigned to the PVID.
Any tagged traffic is filtered according to membership bitmap.At egress, if the vlan matches the PVID, the frame is sent
untagged. Otherwise the frame is sent tagged.Signed-off-by: Vlad Yasevich
Signed-off-by: David S. Miller