[PATCH net-next 1/2] net: bridge: Install FDB for bridge MAC on VLAN 0

[PATCH net-next 1/2] net: bridge: Install FDB for bridge MAC on VLAN 0

[Petr Machata]

Currently, after the bridge is created, the FDB does not hold an FDB entry
for the bridge MAC on VLAN 0:

 # ip link add name br up type bridge
 # ip -br link show dev br
 br               UNKNOWN        92:19:8c:4e:01:ed <BROADCAST,MULTICAST,UP,LOWER_UP>
 # bridge fdb show | grep 92:19:8c:4e:01:ed
 92:19:8c:4e:01:ed dev br vlan 1 master br permanent

Later when the bridge MAC is changed, or in fact when the address is given
during netdevice creation, the entry appears:

 # ip link add name br up address 00:11:22:33:44:55 type bridge
 # bridge fdb show | grep 00:11:22:33:44:55
 00:11:22:33:44:55 dev br vlan 1 master br permanent
 00:11:22:33:44:55 dev br master br permanent

However when the bridge address is set by the user to the current bridge
address before the first port is enslaved, none of the address handlers
gets invoked, because the address is not actually changed. The address is
however marked as NET_ADDR_SET. Then when a port is enslaved, the address
is not changed, because it is NET_ADDR_SET. Thus the VLAN 0 entry is not
added, and it has not been added previously either:

 # ip link add name br up type bridge
 # ip -br link show dev br
 br               UNKNOWN        7e:f0:a8:1a:be:c2 <BROADCAST,MULTICAST,UP,LOWER_UP>
 # ip link set dev br addr 7e:f0:a8:1a:be:c2
 # ip link add name v up type veth
 # ip link set dev v master br
 # ip -br link show dev br
 br               UNKNOWN        7e:f0:a8:1a:be:c2 <BROADCAST,MULTICAST,UP,LOWER_UP>
 # bridge fdb | grep 7e:f0:a8:1a:be:c2
 7e:f0:a8:1a:be:c2 dev br vlan 1 master br permanent

Then when the bridge MAC is used as DMAC, and br_handle_frame_finish()
looks up an FDB entry with VLAN=0, it doesn't find any, and floods the
traffic instead of passing it up.

Fix this by simply adding the VLAN 0 FDB entry for the bridge itself always
on netdevice creation. This also makes the behavior consistent with how
ports are treated: ports always have an FDB entry for each member VLAN as
well as VLAN 0.

Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
---
 net/bridge/br.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/net/bridge/br.c b/net/bridge/br.c
index 512872a2ef81..c37e52e2f29a 100644
--- a/net/bridge/br.c
+++ b/net/bridge/br.c
@@ -37,6 +37,11 @@ static int br_device_event(struct notifier_block *unused, unsigned long event, v
 	int err;
 
 	if (netif_is_bridge_master(dev)) {
+		struct net_bridge *br = netdev_priv(dev);
+
+		if (event == NETDEV_REGISTER)
+			br_fdb_change_mac_address(br, dev->dev_addr);
+
 		err = br_vlan_bridge_event(dev, event, ptr);
 		if (err)
 			return notifier_from_errno(err);
-- 
2.49.0

[PATCH net-next 2/2] selftests: bridge_fdb_local_vlan_0: Test FDB vs. NET_ADDR_SET behavior

[Petr Machata]

The previous patch fixed an issue whereby no FDB entry would be created for
the bridge itself on VLAN 0 under some circumstances. This could break
forwarding. Add a test for the fix.

Signed-off-by: Petr Machata <petrm@nvidia.com>
---
 .../net/forwarding/bridge_fdb_local_vlan_0.sh | 28 ++++++++++++++++---
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/tools/testing/selftests/net/forwarding/bridge_fdb_local_vlan_0.sh b/tools/testing/selftests/net/forwarding/bridge_fdb_local_vlan_0.sh
index 5a0b43aff5aa..65f74c46c2f3 100755
--- a/tools/testing/selftests/net/forwarding/bridge_fdb_local_vlan_0.sh
+++ b/tools/testing/selftests/net/forwarding/bridge_fdb_local_vlan_0.sh
@@ -27,6 +27,7 @@ ALL_TESTS="
 	test_d_sharing
 	test_q_no_sharing
 	test_q_sharing
+	test_addr_set
 "
 
 NUM_NETIFS=6
@@ -110,13 +111,10 @@ setup_prepare()
 	switch_create
 }
 
-adf_bridge_create()
+adf_bridge_configure()
 {
 	local dev
-	local mac
 
-	ip_link_add br up type bridge vlan_default_pvid 0 "$@"
-	mac=$(mac_get br)
 	ip_addr_add br 192.0.2.3/28
 	ip_addr_add br 2001:db8:1::3/64
 
@@ -130,7 +128,15 @@ adf_bridge_create()
 		bridge_vlan_add dev "$dev" vid 2
 		bridge_vlan_add dev "$dev" vid 3
 	done
+}
 
+adf_bridge_create()
+{
+	local mac
+
+	ip_link_add br up type bridge vlan_default_pvid 0 "$@"
+	mac=$(mac_get br)
+	adf_bridge_configure
 	ip_link_set_addr br "$mac"
 }
 
@@ -367,6 +373,20 @@ test_q_sharing()
 	do_test_sharing 1
 }
 
+adf_addr_set_bridge_create()
+{
+	ip_link_add br up type bridge vlan_filtering 0
+	ip_link_set_addr br "$(mac_get br)"
+	adf_bridge_configure
+}
+
+test_addr_set()
+{
+	adf_addr_set_bridge_create
+	setup_wait
+
+	do_end_to_end_test "$(mac_get br)" "NET_ADDR_SET: end to end, br MAC"
+}
 
 trap cleanup EXIT
 
-- 
2.49.0

Re: [PATCH net-next 1/2] net: bridge: Install FDB for bridge MAC on VLAN 0

[Nikolay Aleksandrov]

On 9/22/25 17:14, Petr Machata wrote:
> Currently, after the bridge is created, the FDB does not hold an FDB entry
> for the bridge MAC on VLAN 0:
> 
>   # ip link add name br up type bridge
>   # ip -br link show dev br
>   br               UNKNOWN        92:19:8c:4e:01:ed <BROADCAST,MULTICAST,UP,LOWER_UP>
>   # bridge fdb show | grep 92:19:8c:4e:01:ed
>   92:19:8c:4e:01:ed dev br vlan 1 master br permanent
> 
> Later when the bridge MAC is changed, or in fact when the address is given
> during netdevice creation, the entry appears:
> 
>   # ip link add name br up address 00:11:22:33:44:55 type bridge
>   # bridge fdb show | grep 00:11:22:33:44:55
>   00:11:22:33:44:55 dev br vlan 1 master br permanent
>   00:11:22:33:44:55 dev br master br permanent
> 
> However when the bridge address is set by the user to the current bridge
> address before the first port is enslaved, none of the address handlers
> gets invoked, because the address is not actually changed. The address is
> however marked as NET_ADDR_SET. Then when a port is enslaved, the address
> is not changed, because it is NET_ADDR_SET. Thus the VLAN 0 entry is not
> added, and it has not been added previously either:
> 
>   # ip link add name br up type bridge
>   # ip -br link show dev br
>   br               UNKNOWN        7e:f0:a8:1a:be:c2 <BROADCAST,MULTICAST,UP,LOWER_UP>
>   # ip link set dev br addr 7e:f0:a8:1a:be:c2
>   # ip link add name v up type veth
>   # ip link set dev v master br
>   # ip -br link show dev br
>   br               UNKNOWN        7e:f0:a8:1a:be:c2 <BROADCAST,MULTICAST,UP,LOWER_UP>
>   # bridge fdb | grep 7e:f0:a8:1a:be:c2
>   7e:f0:a8:1a:be:c2 dev br vlan 1 master br permanent
> 
> Then when the bridge MAC is used as DMAC, and br_handle_frame_finish()
> looks up an FDB entry with VLAN=0, it doesn't find any, and floods the
> traffic instead of passing it up.
> 
> Fix this by simply adding the VLAN 0 FDB entry for the bridge itself always
> on netdevice creation. This also makes the behavior consistent with how
> ports are treated: ports always have an FDB entry for each member VLAN as
> well as VLAN 0.
> 
> Signed-off-by: Petr Machata <petrm@nvidia.com>
> Reviewed-by: Ido Schimmel <idosch@nvidia.com>
> ---
>   net/bridge/br.c | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/net/bridge/br.c b/net/bridge/br.c
> index 512872a2ef81..c37e52e2f29a 100644
> --- a/net/bridge/br.c
> +++ b/net/bridge/br.c
> @@ -37,6 +37,11 @@ static int br_device_event(struct notifier_block *unused, unsigned long event, v
>   	int err;
>   
>   	if (netif_is_bridge_master(dev)) {
> +		struct net_bridge *br = netdev_priv(dev);
> +
> +		if (event == NETDEV_REGISTER)
> +			br_fdb_change_mac_address(br, dev->dev_addr);
> +
>   		err = br_vlan_bridge_event(dev, event, ptr);
>   		if (err)
>   			return notifier_from_errno(err);

Acked-by: Nikolay Aleksandrov <razor@blackwall.org>

Re: [PATCH net-next 2/2] selftests: bridge_fdb_local_vlan_0: Test FDB vs. NET_ADDR_SET behavior

[Nikolay Aleksandrov]

On 9/22/25 17:14, Petr Machata wrote:
> The previous patch fixed an issue whereby no FDB entry would be created for
> the bridge itself on VLAN 0 under some circumstances. This could break
> forwarding. Add a test for the fix.
> 
> Signed-off-by: Petr Machata <petrm@nvidia.com>
> ---
>   .../net/forwarding/bridge_fdb_local_vlan_0.sh | 28 ++++++++++++++++---
>   1 file changed, 24 insertions(+), 4 deletions(-)
> 

Acked-by: Nikolay Aleksandrov <razor@blackwall.org>

Re: [PATCH net-next 1/2] net: bridge: Install FDB for bridge MAC on VLAN 0

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Mon, 22 Sep 2025 16:14:48 +0200 you wrote:
> Currently, after the bridge is created, the FDB does not hold an FDB entry
> for the bridge MAC on VLAN 0:
> 
>  # ip link add name br up type bridge
>  # ip -br link show dev br
>  br               UNKNOWN        92:19:8c:4e:01:ed <BROADCAST,MULTICAST,UP,LOWER_UP>
>  # bridge fdb show | grep 92:19:8c:4e:01:ed
>  92:19:8c:4e:01:ed dev br vlan 1 master br permanent
> 
> [...]

Here is the summary with links:
  - [net-next,1/2] net: bridge: Install FDB for bridge MAC on VLAN 0
    https://git.kernel.org/netdev/net-next/c/cd9a9562b255
  - [net-next,2/2] selftests: bridge_fdb_local_vlan_0: Test FDB vs. NET_ADDR_SET behavior
    https://git.kernel.org/netdev/net-next/c/f67e9ae72dd7

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html