Make any attributes newly-added to br_port_policy or vlan_tunnel_policy
parsed strictly, to prevent userspace from passing garbage. Note that this
patchset only touches the former policy. The latter was adjusted for
completeness' sake. There do not appear to be other _deprecated calls
with non-NULL
The MDB maintained by the bridge is limited. When the bridge is configured
for IGMP / MLD snooping, a buggy or malicious client can easily exhaust its
capacity. In SW datapath, the capacity is configurable through the
IFLA_BR_MCAST_HASH_MAX parameter, but ultimately is finite. Obviously a
similar l
Now that br_multicast_new_port_group() takes an extack argument, move
setting the extack there. The downside is that the error messages end
up being less specific (the function cannot distinguish between (S,G)
and (*,G) groups). However, the alternative is to check in the caller
whether the callee
Make it possible to set an extack in br_multicast_new_port_group().
Eventually, this function will check for per-port and per-port-vlan
MDB maximums, and will use the extack to communicate the reason for
the bounce.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
---
net/bridge/br_mdb.c
Since cleaning up the effects of br_multicast_new_port_group() just
consists of delisting and freeing the memory, the function
br_mdb_add_group_star_g() inlines the corresponding code. In the following
patches, number of per-port and per-port-VLAN MDB entries is going to be
maintained, and that cou
The following patch will add two more maximum MDB allowances to the global
one, mcast_hash_max, that exists today. In all these cases, attempts to add
MDB entries above the configured maximums through netlink, fail noisily and
obviously. Such visibility is missing when adding entries through the
co
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
Reviewed-by: Ido Schimmel
---
net/bridge/br_multicast.c | 7 +--
1 file changed, 5 insertion
These functions will be helpful for other testsuites as well. Extract them
to a common place.
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
---
.../selftests/net/forwarding/bridge_mdb.sh| 49 ---
tools/testing/selftests/net/forwarding/lib.sh | 49 +++
The MDB maintained by the bridge is limited. When the bridge is configured
for IGMP / MLD snooping, a buggy or malicious client can easily exhaust its
capacity. In SW datapath, the capacity is configurable through the
IFLA_BR_MCAST_HASH_MAX parameter, but ultimately is finite. Obviously a
similar l
In order to generate IGMPv3 and MLDv2 packets on the fly, we will need
helpers to expand IPv4 and IPv6 addresses given as parameters in
mausezahn payload notation. Add helpers that do it.
Signed-off-by: Petr Machata
---
tools/testing/selftests/net/forwarding/lib.sh | 37 +++
1 fi
Add the letter missing from the word "INCLUDE".
Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
---
tools/testing/selftests/net/forwarding/bridge_mdb.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/forwarding/bridge_mdb.sh
b/tools/testin
The previous patch added accounting for number of MDB entries per port and
per port-VLAN, and the logic to verify that these values stay within
configured bounds. However it didn't provide means to actually configure
those bounds or read the occupancy. This patch does that.
Two new netlink attribu
In order to generate IGMPv3 and MLDv2 packets on the fly, we will need
helpers to calculate the packet checksum.
The approach presented in this patch revolves around payload templates
for mausezahn. These are mausezahn-like payload strings (01:23:45:...)
with possibly one 2-byte sequence replaced
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 Mach
In order to generate IGMPv3 and MLDv2 packets on the fly, the
functions that generate these packets need to be able to generate
packets for different groups and different sources. Generating MLDv2
packets further needs the source address of the packet for purposes of
checksum calculation. Add the n
Add a suite covering mcast_n_groups and mcast_max_groups bridge features.
Signed-off-by: Petr Machata
---
.../testing/selftests/net/forwarding/Makefile | 1 +
.../net/forwarding/bridge_mdb_max.sh | 970 ++
2 files changed, 971 insertions(+)
create mode 100755 tools/te
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
---
tools/testing/selftests/net/forwarding/lib.sh | 50 +
On Thu, 26 Jan 2023 18:01:14 +0100
Petr Machata wrote:
> The following patch will add two more maximum MDB allowances to the global
> one, mcast_hash_max, that exists today. In all these cases, attempts to add
> MDB entries above the configured maximums through netlink, fail noisily and
> obvious
From: Leon Romanovsky
In netdev common pattern, xxtack 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 ca
On Thu, 26 Jan 2023 18:01:09 +0100
Petr Machata wrote:
> static const struct nla_policy br_port_policy[IFLA_BRPORT_MAX + 1] = {
> + [IFLA_BRPORT_UNSPEC]= { .strict_start_type =
> + IFLA_BRPORT_MCAST_EHT_HOSTS_LIMIT + 1 },
Is the original IFLA_BRPORT a
On January 26, 2023 9:18:43 PM GMT+02:00, Stephen Hemminger
wrote:
>On Thu, 26 Jan 2023 18:01:09 +0100
>Petr Machata wrote:
>
>> static const struct nla_policy br_port_policy[IFLA_BRPORT_MAX + 1] = {
>> +[IFLA_BRPORT_UNSPEC]= { .strict_start_type =
>> +
On January 26, 2023 7:01:08 PM GMT+02:00, Petr Machata wrote:
>The MDB maintained by the bridge is limited. When the bridge is configured
>for IGMP / MLD snooping, a buggy or malicious client can easily exhaust its
>capacity. In SW datapath, the capacity is configurable through the
>IFLA_BR_MCAST_
On Thu, Jan 26, 2023 at 09:15:03PM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> In netdev common pattern, xxtack pointer is forwarded to the drivers
~~
extack
> to be filled with error message. However, the caller can easil
On Fri, 27 Jan 2023 00:32:13 +0200 Vladimir Oltean wrote:
> On Thu, Jan 26, 2023 at 09:15:03PM +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky
> >
> > In netdev common pattern, xxtack pointer is forwarded to the drivers
> ~~
>
On Thu, Jan 26, 2023 at 02:37:23PM -0800, Jakub Kicinski wrote:
> > I would somewhat prefer not doing this, and instead introducing a new
> > NL_SET_ERR_MSG_WEAK() of sorts.
>
> That'd be my preference too, FWIW. It's only the offload cases which
> need this sort of fallback.
>
> BTW Vladimir, I
On Fri, 27 Jan 2023 00:44:57 +0200 Vladimir Oltean wrote:
> On Thu, Jan 26, 2023 at 02:37:23PM -0800, Jakub Kicinski wrote:
> > > I would somewhat prefer not doing this, and instead introducing a new
> > > NL_SET_ERR_MSG_WEAK() of sorts.
> >
> > That'd be my preference too, FWIW. It's only the o
On Fri, Jan 27, 2023 at 12:32:13AM +0200, Vladimir Oltean wrote:
> On Thu, Jan 26, 2023 at 09:15:03PM +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky
> >
> > In netdev common pattern, xxtack pointer is forwarded to the drivers
> ~~
>
On Thu, Jan 26, 2023 at 02:37:23PM -0800, Jakub Kicinski wrote:
> On Fri, 27 Jan 2023 00:32:13 +0200 Vladimir Oltean wrote:
> > On Thu, Jan 26, 2023 at 09:15:03PM +0200, Leon Romanovsky wrote:
> > > From: Leon Romanovsky
> > >
> > > In netdev common pattern, xxtack pointer is forwarded to the dri
On Fri, 27 Jan 2023 07:26:13 +0200 Leon Romanovsky wrote:
> > That'd be my preference too, FWIW. It's only the offload cases which
> > need this sort of fallback.
>
> Of course not, almost any error unwind path which sets extack will need it.
I guess we can come up with scenarios where the new
29 matches
Mail list logo
