search for: blackwall

...CAST_TO_UCAST conversion in their own FW to reduce CPU. So, the best way is to have MCAST_TO_UCAST enabled and MDB will become per station, so we can delete MDB on disconnect. Shall, I create one patch for review? Thanks, UjjaL Roy On Mon, Mar 20, 2023 at 5:38?PM Nikolay Aleksandrov <razor at blackwall.org> wrote: > > On 20/03/2023 13:45, Ujjal Roy wrote: > > Hi Nikolay, > > > > I have some query on multicast. When streams running on an STA and STA > > disconnected due to some reason. So, until the MDB is timed out the > > stream will be forwarded to the por...

This function is getting more to clean up in the following patches. Structuring the cleanups in one labeled block will allow reusing the same cleanup from several places. Signed-off-by: Petr Machata <petrm at nvidia.com> Reviewed-by: Ido Schimmel <idosch at nvidia.com> --- net/bridge/br_multicast.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git

The testsuite that checks for mcast_max_groups functionality will need to wipe the added groups as well. Add helpers to build an IGMP or MLD packets announcing that host is leaving a given group. Signed-off-by: Petr Machata <petrm at nvidia.com> --- tools/testing/selftests/net/forwarding/lib.sh | 50 +++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git

...| 83 +++++++++++++++++++++++++++++++++++++++++ > net/bridge/br_device.c | 4 +- > net/bridge/br_private.h | 9 +++++ > 3 files changed, 95 insertions(+), 1 deletion(-) > The bridge doesn't need private sysctls. Netlink is enough. Nacked-by: Nikolay Aleksandrov <razor at blackwall.org>

..._ERR_MSG_MOD(extack, > "STP can't be enabled if MRP is already enabled"); Oh well, I guess this should do for now. Hopefully we don't break scripts that rely on configuring the bridge without any errors. Thanks for the patch, Acked-by: Nikolay Aleksandrov <razor at blackwall.org>

The testsuite that checks for mcast_max_groups functionality will need to generate IGMP and MLD packets with configurable number of (S,G) addresses. To that end, further extend igmpv3_is_in_get() and mldv2_is_in_get() to allow a list of IP addresses instead of one address. Signed-off-by: Petr Machata <petrm at nvidia.com> --- tools/testing/selftests/net/forwarding/lib.sh | 22

Since commit 19e3a9c90c53 ("net: bridge: convert multicast to generic rhashtable") this is not used, so can remove it. Signed-off-by: YueHaibing <yuehaibing at huawei.com> --- net/bridge/br_private.h | 1 - 1 file changed, 1 deletion(-) diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h index 51e4ca54b537..a1f4acfa6994 100644 --- a/net/bridge/br_private.h +++

On 20/03/2023 13:45, Ujjal Roy wrote: > Hi Nikolay, > > I have some query on multicast. When streams running on an STA and STA > disconnected due to some reason. So, until the MDB is timed out the > stream will be forwarded to the port and in turn to the driver and > dropps there as no such STA. > > So, is the multicast_eht handling this scenario to take any action >

These functions will be helpful for other testsuites as well. Extract them to a common place. Signed-off-by: Petr Machata <petrm at nvidia.com> Reviewed-by: Ido Schimmel <idosch at nvidia.com> --- .../selftests/net/forwarding/bridge_mdb.sh | 49 ------------------- tools/testing/selftests/net/forwarding/lib.sh | 49 +++++++++++++++++++ 2 files changed, 49 insertions(+), 49

Add MDB net device operations that will be invoked by rtnetlink code in response to received RTM_{NEW,DEL,GET}MDB messages. Subsequent patches will implement these operations in the bridge and VXLAN drivers. Signed-off-by: Ido Schimmel <idosch at nvidia.com> --- include/linux/netdevice.h | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/include/linux/netdevice.h

When we create an L2 loop on a bridge in netns, we will see packets storm even if STP is enabled. # unshare -n # ip link add br0 type bridge # ip link add veth0 type veth peer name veth1 # ip link set veth0 master br0 up # ip link set veth1 master br0 up # ip link set br0 type bridge stp_state 1 # ip link set br0 up # sleep 30 # ip -s link show br0 2: br0:

In netdev common pattern, extack pointer is forwarded to the drivers to be filled with error message. However, the caller can easily overwrite the filled message. Instead of adding multiple "if (!extack->_msg)" checks before any NL_SET_ERR_MSG() call, which appears after call to the driver, let's add new macro to common code. [1] https://lore.kernel.org/all/Y9Irgrgf3uxOjwUm at

Adjust drivers that support the 'FLOW_DISSECTOR_KEY_META' key to reject filters that try to match on the newly added layer 2 miss option. Add an extack message to clearly communicate the failure reason to user space. Example: # tc filter add dev swp1 egress pref 1 proto all flower skip_sw l2_miss true action drop Error: mlxsw_spectrum: Can't match on "l2_miss". We have

Support setting the FDB limit through ip link. The arguments is: - fdb_max_learned: A 32-bit unsigned integer specifying the maximum number of learned FDB entries, with 0 disabling the limit. Also support reading back the current number of learned FDB entries in the bridge by this count. The returned value's name is: - fdb_n_learned: A 32-bit unsigned

From: Nikolay Aleksandrov <nikolay at cumulusnetworks.com> This patch allows the user to set and retrieve speed and duplex of the virtio_net device via ethtool. Having this functionality is very helpful for simulating different environments and also enables the virtio_net device to participate in operations where proper speed and duplex are required (e.g. currently bonding lacp mode

From: Nikolay Aleksandrov <nikolay at cumulusnetworks.com> This patch allows the user to set and retrieve speed and duplex of the virtio_net device via ethtool. Having this functionality is very helpful for simulating different environments and also enables the virtio_net device to participate in operations where proper speed and duplex are required (e.g. currently bonding lacp mode

A malicious actor behind one bridge port may spam the kernel with packets with a random source MAC address, each of which will create an FDB entry, each of which is a dynamic allocation in the kernel. There are roughly 2^48 different MAC addresses, further limited by the rhashtable they are stored in to 2^31. Each entry is of the type struct net_bridge_fdb_entry, which is currently 128 bytes big.

Hi Ziqi, On 8/19/23 11:10, Ziqi Zhao wrote: > In the bug reported by Syzbot, certain bridge devices would have a > leaked reference created by race conditions in dev_ioctl, specifically, > under SIOCBRADDIF or SIOCBRDELIF operations. The reference leak would How would it leak a reference, could you elaborate? The reference is always taken and always released after the call. > be

On 15/05/2023 11:50, Johannes Nixdorf wrote: > A malicious actor behind one bridge port may spam the kernel with packets > with a random source MAC address, each of which will create an FDB entry, > each of which is a dynamic allocation in the kernel. > > There are roughly 2^48 different MAC addresses, further limited by the > rhashtable they are stored in to 2^31. Each entry is

On 8/20/23 01:50, Ziqi Zhao wrote: > On Sat, Aug 19, 2023 at 12:25:15PM +0300, Nikolay Aleksandrov wrote: > Hi Nik, > > Thank you so much for reviewing the patch and getting back to me! > >> IIRC there was no bug, it was a false-positive. The reference is held a bit >> longer but then released, so the device is deleted later. > >> If you reproduced it, is the