search for: fdb_delete

...by netlink or from bridge or bridge port addresses are never blocked and do not count towards that limit. All changes to fdb_n_entries are under br->hash_lock, which means we do not need additional locking. The call paths are (? denotes that br->hash_lock is taken around the next call): - fdb_delete <-+- fdb_delete_local <-+- br_fdb_changeaddr ? | +- br_fdb_change_mac_address ? | +- br_fdb_delete_by_port ? +- br_fdb_find_delete_local ? +- fdb_add_local <-+- br_fdb_changeaddr ?...

...ies to a user specified maximum. For backwards compatibility the default setting of 0 disables the limit. All changes to fdb_n_entries are under br->hash_lock, which means we do not need additional locking. The call paths are (? denotes that br->hash_lock is taken around the next call): - fdb_delete <-+- fdb_delete_local <-+- br_fdb_changeaddr ? | +- br_fdb_change_mac_address ? | +- br_fdb_delete_by_port ? +- br_fdb_find_delete_local ? +- fdb_add_local <-+- br_fdb_changeaddr ?...

...gt; For backwards compatibility the default setting of 0 disables the limit. > > All changes to fdb_n_entries are under br->hash_lock, which means we do > not need additional locking. The call paths are (? denotes that > br->hash_lock is taken around the next call): > > - fdb_delete <-+- fdb_delete_local <-+- br_fdb_changeaddr ? > | +- br_fdb_change_mac_address ? > | +- br_fdb_delete_by_port ? > +- br_fdb_find_delete_local ? > +- fdb_add_local <-+- br_fd...

...the HW address from that entry is > > * also removed from the bridge private HW address list and updates all > > * the ports with needed information. > > @@ -321,6 +353,8 @@ static void fdb_del_hw_addr(struct net_bridge *br, const unsigned char *addr) > > static void fdb_delete(struct net_bridge *br, struct net_bridge_fdb_entry *f, > > bool swdev_notify) > > { > > + bool learned = !(f->flags & BR_FDB_NOT_LEARNED_MASK); > > *_bit I do not know a *_bit helper that would help me test the intersection of multiple bits on both side...

...ss from that entry is >>> * also removed from the bridge private HW address list and updates all >>> * the ports with needed information. >>> @@ -321,6 +353,8 @@ static void fdb_del_hw_addr(struct net_bridge *br, const unsigned char *addr) >>> static void fdb_delete(struct net_bridge *br, struct net_bridge_fdb_entry *f, >>> bool swdev_notify) >>> { >>> + bool learned = !(f->flags & BR_FDB_NOT_LEARNED_MASK); >> >> *_bit > > I do not know a *_bit helper that would help me test the intersection &gt...

Introduce a limit on the amount of learned FDB entries on a bridge, configured by netlink with a build time default on bridge creation in the kernel config. For backwards compatibility the kernel config default is disabling the limit (0). Without any limit a malicious actor may OOM a kernel by spamming packets with changing MAC addresses on their bridge port, so allow the bridge creator to limit

...(x << 2) ^ mac[1]; - x = (x << 2) ^ mac[2]; - x = (x << 2) ^ mac[3]; - x = (x << 2) ^ mac[4]; - x = (x << 2) ^ mac[5]; - - x ^= x >> 8; - - return x & (BR_HASH_SIZE - 1); + return jhash(mac, ETH_ALEN, 0) & (BR_HASH_SIZE - 1); } static __inline__ void fdb_delete(struct net_bridge_fdb_entry *f)

...vid < BR_VLAN_BITMAP_LEN; - vid = find_next_bit(pv->vlan_bitmap, BR_VLAN_BITMAP_LEN, vid+1)) { + for_each_set_bit_from(vid, pv->vlan_bitmap, BR_VLAN_BITMAP_LEN) { f = __br_fdb_get(br, br->dev->dev_addr, vid); if (f && f->is_local && !f->dst) fdb_delete(br, f);

..._to_* calls into a single interface * Fixed the rest of the issues report by Michal Miroslaw * Fixed a bug where fdb entries were not created for all added vlans. Changes since v7: * Rebases on the latest net-next and removed the vlan wrapper patch from the series. * Fixed a crash in br_fdb_add/br_fdb_delete. Changes since v6: * VLANs are now stored in a VLAN bitmap per port. This allows for O(1) lookup at ingress and egress. We simply check to see if the bit associated with the vlan id is set in the map. The drawback to this approach is that it wastes some space when there is only a small number o...

...spin_lock_bh(&br->hash_lock); fdb = br_fdb_find(br, addr, vid); - if (fdb && test_bit(BR_FDB_ADDED_BY_EXT_LEARN, &fdb->flags)) + if (fdb && + (test_bit(BR_FDB_ADDED_BY_EXT_LEARN, &fdb->flags) || + test_bit(BR_FDB_OFFLOADED, &fdb->flags))) fdb_delete(br, fdb, swdev_notify); else err = -ENOENT; A reasonable question you could ask yourself is: why do my BR_FDB_OFFLOADED entries have this flag in the software bridge in the first place? Did I add code for it? Is it because there is some difference between mv88e6xxx and ocelot/felix, or is it...

...b); - br_fdb_put(dst); - } else + else br_flood_deliver(br, skb, 0); rcu_read_unlock(); diff -Nru a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c --- a/net/bridge/br_fdb.c 2004-07-28 15:30:04 -07:00 +++ b/net/bridge/br_fdb.c 2004-07-28 15:30:04 -07:00 @@ -73,7 +73,7 @@ static __inline__ void fdb_delete(struct net_bridge_fdb_entry *f) { - hlist_del(&f->hlist); + hlist_del_rcu(&f->hlist); if (!f->is_static) list_del(&f->age_list); @@ -85,7 +85,7 @@ struct net_bridge *br = p->br; int i; - write_lock_bh(&br->hash_lock); + spin_lock_bh(&br->hash_...

On Mon, Mar 27, 2023 at 14:52, Vladimir Oltean <olteanv at gmail.com> wrote: > > By the way, there is a behavior change here. > > Before: > > $ ip link add br0 type bridge && ip link set br0 up > $ ip link set swp0 master br0 && ip link set swp0 up > $ bridge fdb add dev swp0 00:01:02:03:04:05 master dynamic > [ 70.010181] mscc_felix 0000:00:00.5:

This series of patches provides an ability to add VLANs to the bridge ports. This is similar to what can be found in most switches. The bridge port may have any number of VLANs added to it including vlan 0 priority tagged traffic. When vlans are added to the port, only traffic tagged with particular vlan will forwarded over this port. Additionally, vlan ids are added to FDB entries and become