netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 net-next] net: bridge: propagate error code and extack from br_mc_disabled_update
@ 2021-04-14 19:22 Vladimir Oltean
  2021-04-14 21:40 ` patchwork-bot+netdevbpf
  2021-04-21 18:18 ` Christian Borntraeger
  0 siblings, 2 replies; 7+ messages in thread
From: Vladimir Oltean @ 2021-04-14 19:22 UTC (permalink / raw)
  To: Jakub Kicinski, David S. Miller, netdev
  Cc: Florian Fainelli, Andrew Lunn, Jiri Pirko, Ido Schimmel,
	Roopa Prabhu, Nikolay Aleksandrov, Vladimir Oltean

From: Florian Fainelli <f.fainelli@gmail.com>

Some Ethernet switches might only be able to support disabling multicast
snooping globally, which is an issue for example when several bridges
span the same physical device and request contradictory settings.

Propagate the return value of br_mc_disabled_update() such that this
limitation is transmitted correctly to user-space.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v2: Overwrite -EOPNOTSUPP with 0 so that br_multicast_toggle doesn't
leak that return value to the caller.

@Nikolay:

[root@LS1028ARDB ~/selftests/net/forwarding] # ./bridge_igmp.sh one two three four
[   45.476399] IPv6: ADDRCONF(NETDEV_CHANGE): one: link becomes ready
[   45.484079] IPv6: ADDRCONF(NETDEV_CHANGE): two: link becomes ready
[   45.559919] br0: port 1(two) entered blocking state
[   45.564965] br0: port 1(two) entered disabled state
[   45.570849] device two entered promiscuous mode
[   45.580737] br0: port 2(three) entered blocking state
[   45.585967] br0: port 2(three) entered disabled state
[   45.591850] device three entered promiscuous mode
[   45.601280] br0: port 1(two) entered blocking state
[   45.606229] br0: port 1(two) entered forwarding state
[   45.620600] br0: port 2(three) entered blocking state
[   45.625719] br0: port 2(three) entered forwarding state
[   45.631438] IPv6: ADDRCONF(NETDEV_CHANGE): four: link becomes ready
TEST: IGMPv2 report 239.10.10.10                                    [ OK ]
TEST: IGMPv2 leave 239.10.10.10                                     [ OK ]
TEST: IGMPv3 report 239.10.10.10 is_include                         [ OK ]
TEST: IGMPv3 report 239.10.10.10 include -> allow                   [ OK ]
TEST: IGMPv3 report 239.10.10.10 include -> is_include              [ OK ]
TEST: IGMPv3 report 239.10.10.10 include -> is_exclude              [ OK ]
TEST: IGMPv3 report 239.10.10.10 include -> to_exclude              [ OK ]
TEST: IGMPv3 report 239.10.10.10 exclude -> allow                   [ OK ]
TEST: IGMPv3 report 239.10.10.10 exclude -> is_include              [ OK ]
TEST: IGMPv3 report 239.10.10.10 exclude -> is_exclude              [ OK ]
TEST: IGMPv3 report 239.10.10.10 exclude -> to_exclude              [ OK ]
TEST: IGMPv3 report 239.10.10.10 include -> block                   [ OK ]
TEST: IGMPv3 report 239.10.10.10 exclude -> block                   [ OK ]
TEST: IGMPv3 group 239.10.10.10 exclude timeout                     [ OK ]
TEST: IGMPv3 S,G port entry automatic add to a *,G port             [ OK ]
[  160.556931] br0: port 2(three) entered disabled state
[  160.567926] br0: port 1(two) entered disabled state
[  160.578931] device three left promiscuous mode
[  160.584403] br0: port 2(three) entered disabled state
[  160.604206] device two left promiscuous mode
[  160.608837] br0: port 1(two) entered disabled state
RTNETLINK answers: Cannot assign requested address
[root@LS1028ARDB ~/selftests/net/forwarding] # ./bridge_mld.sh one two three four
[  168.606290] IPv6: ADDRCONF(NETDEV_CHANGE): one: link becomes ready
[  168.614313] IPv6: ADDRCONF(NETDEV_CHANGE): two: link becomes ready
[  168.653335] IPv6: ADDRCONF(NETDEV_CHANGE): four: link becomes ready
[  168.661972] IPv6: ADDRCONF(NETDEV_CHANGE): three: link becomes ready
[  168.680831] br0: port 1(two) entered blocking state
[  168.686361] br0: port 1(two) entered disabled state
[  168.692220] device two entered promiscuous mode
[  168.701535] br0: port 2(three) entered blocking state
[  168.706656] br0: port 2(three) entered disabled state
[  168.712105] device three entered promiscuous mode
[  168.722046] br0: port 2(three) entered blocking state
[  168.727150] br0: port 2(three) entered forwarding state
[  168.732484] br0: port 1(two) entered blocking state
[  168.737408] br0: port 1(two) entered forwarding state
TEST: MLDv2 report ff02::cc is_include                              [ OK ]
TEST: MLDv2 report ff02::cc include -> allow                        [ OK ]
TEST: MLDv2 report ff02::cc include -> is_include                   [ OK ]
TEST: MLDv2 report ff02::cc include -> is_exclude                   [ OK ]
TEST: MLDv2 report ff02::cc include -> to_exclude                   [ OK ]
TEST: MLDv2 report ff02::cc exclude -> allow                        [ OK ]
TEST: MLDv2 report ff02::cc exclude -> is_include                   [ OK ]
TEST: MLDv2 report ff02::cc exclude -> is_exclude                   [ OK ]
TEST: MLDv2 report ff02::cc exclude -> to_exclude                   [ OK ]
TEST: MLDv2 report ff02::cc include -> block                        [ OK ]
TEST: MLDv2 report ff02::cc exclude -> block                        [ OK ]
TEST: MLDv2 group ff02::cc exclude timeout                          [ OK ]
TEST: MLDv2 S,G port entry automatic add to a *,G port              [ OK ]
[  276.401190] br0: port 2(three) entered disabled state
[  276.414596] br0: port 1(two) entered disabled state
[  276.424809] device three left promiscuous mode
[  276.429494] br0: port 2(three) entered disabled state
[  276.444132] device two left promiscuous mode
[  276.449101] br0: port 1(two) entered disabled state

It might be helpful to enforce a check in these selftests for the
version of the bridge binary, it must be >= v5.10 due to your checking
for "source_list" in the 'bridge mdb' json output.

I tried to do this, and my bridge compiled from source says:

[root@LS1028ARDB ~/selftests/net/forwarding] # bridge -V
bridge utility, 5.11.0

but I suspect that the bridge utility shipped by most if not all
distributions just return:

$ bridge -V
bridge utility, 0.0

So I'm not sure how we can actually enforce this version check, but it
would be nonetheless useful for the selftests to auto-detect if the
bridge binary has this feature or not.

 net/bridge/br_multicast.c | 28 +++++++++++++++++++++-------
 net/bridge/br_netlink.c   |  4 +++-
 net/bridge/br_private.h   |  3 ++-
 net/bridge/br_sysfs_br.c  |  8 +-------
 4 files changed, 27 insertions(+), 16 deletions(-)

diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 9d265447d654..4daa95c913d0 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1593,7 +1593,8 @@ static void br_multicast_port_group_rexmit(struct timer_list *t)
 	spin_unlock(&br->multicast_lock);
 }
 
-static void br_mc_disabled_update(struct net_device *dev, bool value)
+static int br_mc_disabled_update(struct net_device *dev, bool value,
+				 struct netlink_ext_ack *extack)
 {
 	struct switchdev_attr attr = {
 		.orig_dev = dev,
@@ -1602,11 +1603,13 @@ static void br_mc_disabled_update(struct net_device *dev, bool value)
 		.u.mc_disabled = !value,
 	};
 
-	switchdev_port_attr_set(dev, &attr, NULL);
+	return switchdev_port_attr_set(dev, &attr, extack);
 }
 
 int br_multicast_add_port(struct net_bridge_port *port)
 {
+	int err;
+
 	port->multicast_router = MDB_RTR_TYPE_TEMP_QUERY;
 	port->multicast_eht_hosts_limit = BR_MCAST_DEFAULT_EHT_HOSTS_LIMIT;
 
@@ -1618,8 +1621,12 @@ int br_multicast_add_port(struct net_bridge_port *port)
 	timer_setup(&port->ip6_own_query.timer,
 		    br_ip6_multicast_port_query_expired, 0);
 #endif
-	br_mc_disabled_update(port->dev,
-			      br_opt_get(port->br, BROPT_MULTICAST_ENABLED));
+	err = br_mc_disabled_update(port->dev,
+				    br_opt_get(port->br,
+					       BROPT_MULTICAST_ENABLED),
+				    NULL);
+	if (err)
+		return err;
 
 	port->mcast_stats = netdev_alloc_pcpu_stats(struct bridge_mcast_stats);
 	if (!port->mcast_stats)
@@ -3560,16 +3567,23 @@ static void br_multicast_start_querier(struct net_bridge *br,
 	rcu_read_unlock();
 }
 
-int br_multicast_toggle(struct net_bridge *br, unsigned long val)
+int br_multicast_toggle(struct net_bridge *br, unsigned long val,
+			struct netlink_ext_ack *extack)
 {
 	struct net_bridge_port *port;
 	bool change_snoopers = false;
+	int err = 0;
 
 	spin_lock_bh(&br->multicast_lock);
 	if (!!br_opt_get(br, BROPT_MULTICAST_ENABLED) == !!val)
 		goto unlock;
 
-	br_mc_disabled_update(br->dev, val);
+	err = br_mc_disabled_update(br->dev, val, extack);
+	if (err == -EOPNOTSUPP)
+		err = 0;
+	if (err)
+		goto unlock;
+
 	br_opt_toggle(br, BROPT_MULTICAST_ENABLED, !!val);
 	if (!br_opt_get(br, BROPT_MULTICAST_ENABLED)) {
 		change_snoopers = true;
@@ -3607,7 +3621,7 @@ int br_multicast_toggle(struct net_bridge *br, unsigned long val)
 			br_multicast_leave_snoopers(br);
 	}
 
-	return 0;
+	return err;
 }
 
 bool br_multicast_enabled(const struct net_device *dev)
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index f2b1343f8332..0456593aceec 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -1293,7 +1293,9 @@ static int br_changelink(struct net_device *brdev, struct nlattr *tb[],
 	if (data[IFLA_BR_MCAST_SNOOPING]) {
 		u8 mcast_snooping = nla_get_u8(data[IFLA_BR_MCAST_SNOOPING]);
 
-		br_multicast_toggle(br, mcast_snooping);
+		err = br_multicast_toggle(br, mcast_snooping, extack);
+		if (err)
+			return err;
 	}
 
 	if (data[IFLA_BR_MCAST_QUERY_USE_IFADDR]) {
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 50747990188e..7ce8a77cc6b6 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -810,7 +810,8 @@ void br_multicast_flood(struct net_bridge_mdb_entry *mdst,
 			struct sk_buff *skb, bool local_rcv, bool local_orig);
 int br_multicast_set_router(struct net_bridge *br, unsigned long val);
 int br_multicast_set_port_router(struct net_bridge_port *p, unsigned long val);
-int br_multicast_toggle(struct net_bridge *br, unsigned long val);
+int br_multicast_toggle(struct net_bridge *br, unsigned long val,
+			struct netlink_ext_ack *extack);
 int br_multicast_set_querier(struct net_bridge *br, unsigned long val);
 int br_multicast_set_hash_max(struct net_bridge *br, unsigned long val);
 int br_multicast_set_igmp_version(struct net_bridge *br, unsigned long val);
diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
index 072e29840082..381467b691d5 100644
--- a/net/bridge/br_sysfs_br.c
+++ b/net/bridge/br_sysfs_br.c
@@ -409,17 +409,11 @@ static ssize_t multicast_snooping_show(struct device *d,
 	return sprintf(buf, "%d\n", br_opt_get(br, BROPT_MULTICAST_ENABLED));
 }
 
-static int toggle_multicast(struct net_bridge *br, unsigned long val,
-			    struct netlink_ext_ack *extack)
-{
-	return br_multicast_toggle(br, val);
-}
-
 static ssize_t multicast_snooping_store(struct device *d,
 					struct device_attribute *attr,
 					const char *buf, size_t len)
 {
-	return store_bridge_parm(d, buf, len, toggle_multicast);
+	return store_bridge_parm(d, buf, len, br_multicast_toggle);
 }
 static DEVICE_ATTR_RW(multicast_snooping);
 
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH v2 net-next] net: bridge: propagate error code and extack from br_mc_disabled_update
  2021-04-14 19:22 [PATCH v2 net-next] net: bridge: propagate error code and extack from br_mc_disabled_update Vladimir Oltean
@ 2021-04-14 21:40 ` patchwork-bot+netdevbpf
  2021-04-21 18:18 ` Christian Borntraeger
  1 sibling, 0 replies; 7+ messages in thread
From: patchwork-bot+netdevbpf @ 2021-04-14 21:40 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: kuba, davem, netdev, f.fainelli, andrew, jiri, idosch, roopa,
	nikolay, vladimir.oltean

Hello:

This patch was applied to netdev/net-next.git (refs/heads/master):

On Wed, 14 Apr 2021 22:22:57 +0300 you wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
> 
> Some Ethernet switches might only be able to support disabling multicast
> snooping globally, which is an issue for example when several bridges
> span the same physical device and request contradictory settings.
> 
> Propagate the return value of br_mc_disabled_update() such that this
> limitation is transmitted correctly to user-space.
> 
> [...]

Here is the summary with links:
  - [v2,net-next] net: bridge: propagate error code and extack from br_mc_disabled_update
    https://git.kernel.org/netdev/net-next/c/ae1ea84b33da

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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: net: bridge: propagate error code and extack from br_mc_disabled_update
  2021-04-14 19:22 [PATCH v2 net-next] net: bridge: propagate error code and extack from br_mc_disabled_update Vladimir Oltean
  2021-04-14 21:40 ` patchwork-bot+netdevbpf
@ 2021-04-21 18:18 ` Christian Borntraeger
  2021-04-21 18:35   ` Christian Borntraeger
  1 sibling, 1 reply; 7+ messages in thread
From: Christian Borntraeger @ 2021-04-21 18:18 UTC (permalink / raw)
  To: olteanv
  Cc: andrew, davem, f.fainelli, idosch, jiri, kuba, netdev, nikolay,
	roopa, vladimir.oltean, linux-next, borntraeger

Whatever version landed in next, according to bisect this broke libvirt/kvms use of bridges:


# virsh start s31128001
error: Failed to start domain 's31128001'
error: Unable to add bridge virbr1 port vnet0: Operation not supported

# grep vnet0 /var/log/libvirt/libvirtd.log

2021-04-21 07:43:09.453+0000: 2460: info : virNetDevTapCreate:240 : created device: 'vnet0'
2021-04-21 07:43:09.453+0000: 2460: debug : virNetDevSetMACInternal:287 : SIOCSIFHWADDR vnet0 MAC=fe:bb:83:28:01:02 - Success
2021-04-21 07:43:09.453+0000: 2460: error : virNetDevBridgeAddPort:633 : Unable to add bridge virbr1 port vnet0: Operation not supported
2021-04-21 07:43:09.466+0000: 2543: debug : udevHandleOneDevice:1695 : udev action: 'add': /sys/devices/virtual/net/vnet0

Christian

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: net: bridge: propagate error code and extack from br_mc_disabled_update
  2021-04-21 18:18 ` Christian Borntraeger
@ 2021-04-21 18:35   ` Christian Borntraeger
  2021-04-21 18:37     ` Florian Fainelli
  0 siblings, 1 reply; 7+ messages in thread
From: Christian Borntraeger @ 2021-04-21 18:35 UTC (permalink / raw)
  To: olteanv
  Cc: andrew, davem, f.fainelli, idosch, jiri, kuba, netdev, nikolay,
	roopa, vladimir.oltean, linux-next, kvm list, linux-s390



On 21.04.21 20:18, Christian Borntraeger wrote:
> Whatever version landed in next, according to bisect this broke libvirt/kvms use of bridges:
> 
> 
> # virsh start s31128001
> error: Failed to start domain 's31128001'
> error: Unable to add bridge virbr1 port vnet0: Operation not supported
> 
> # grep vnet0 /var/log/libvirt/libvirtd.log
> 
> 2021-04-21 07:43:09.453+0000: 2460: info : virNetDevTapCreate:240 : created device: 'vnet0'
> 2021-04-21 07:43:09.453+0000: 2460: debug : virNetDevSetMACInternal:287 : SIOCSIFHWADDR vnet0 MAC=fe:bb:83:28:01:02 - Success
> 2021-04-21 07:43:09.453+0000: 2460: error : virNetDevBridgeAddPort:633 : Unable to add bridge virbr1 port vnet0: Operation not supported
> 2021-04-21 07:43:09.466+0000: 2543: debug : udevHandleOneDevice:1695 : udev action: 'add': /sys/devices/virtual/net/vnet0
> 
> Christian
> 

For reference:

ae1ea84b33dab45c7b6c1754231ebda5959b504c is the first bad commit
commit ae1ea84b33dab45c7b6c1754231ebda5959b504c
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Wed Apr 14 22:22:57 2021 +0300

     net: bridge: propagate error code and extack from br_mc_disabled_update
     
     Some Ethernet switches might only be able to support disabling multicast
     snooping globally, which is an issue for example when several bridges
     span the same physical device and request contradictory settings.
     
     Propagate the return value of br_mc_disabled_update() such that this
     limitation is transmitted correctly to user-space.
     
     Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
     Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
     Signed-off-by: David S. Miller <davem@davemloft.net>

  net/bridge/br_multicast.c | 28 +++++++++++++++++++++-------
  net/bridge/br_netlink.c   |  4 +++-
  net/bridge/br_private.h   |  3 ++-
  net/bridge/br_sysfs_br.c  |  8 +-------
  4 files changed, 27 insertions(+), 16 deletions(-)

not sure if it matters this is on s390.
A simple reproducer is virt-install, e.g.
virt-install --name test --disk size=12 --memory=2048 --vcpus=2 --location http://ports.ubuntu.com/ubuntu-ports/dists/bionic/main/installer-s390x/


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: net: bridge: propagate error code and extack from br_mc_disabled_update
  2021-04-21 18:35   ` Christian Borntraeger
@ 2021-04-21 18:37     ` Florian Fainelli
  2021-04-21 18:46       ` Vladimir Oltean
  0 siblings, 1 reply; 7+ messages in thread
From: Florian Fainelli @ 2021-04-21 18:37 UTC (permalink / raw)
  To: Christian Borntraeger, olteanv
  Cc: andrew, davem, idosch, jiri, kuba, netdev, nikolay, roopa,
	vladimir.oltean, linux-next, kvm list, linux-s390



On 4/21/2021 11:35 AM, Christian Borntraeger wrote:
> 
> 
> On 21.04.21 20:18, Christian Borntraeger wrote:
>> Whatever version landed in next, according to bisect this broke
>> libvirt/kvms use of bridges:
>>
>>
>> # virsh start s31128001
>> error: Failed to start domain 's31128001'
>> error: Unable to add bridge virbr1 port vnet0: Operation not supported
>>
>> # grep vnet0 /var/log/libvirt/libvirtd.log
>>
>> 2021-04-21 07:43:09.453+0000: 2460: info : virNetDevTapCreate:240 :
>> created device: 'vnet0'
>> 2021-04-21 07:43:09.453+0000: 2460: debug :
>> virNetDevSetMACInternal:287 : SIOCSIFHWADDR vnet0
>> MAC=fe:bb:83:28:01:02 - Success
>> 2021-04-21 07:43:09.453+0000: 2460: error : virNetDevBridgeAddPort:633
>> : Unable to add bridge virbr1 port vnet0: Operation not supported
>> 2021-04-21 07:43:09.466+0000: 2543: debug : udevHandleOneDevice:1695 :
>> udev action: 'add': /sys/devices/virtual/net/vnet0
>>
>> Christian
>>
> 
> For reference:
> 
> ae1ea84b33dab45c7b6c1754231ebda5959b504c is the first bad commit
> commit ae1ea84b33dab45c7b6c1754231ebda5959b504c
> Author: Florian Fainelli <f.fainelli@gmail.com>
> Date:   Wed Apr 14 22:22:57 2021 +0300
> 
>    net: bridge: propagate error code and extack from br_mc_disabled_update
>       Some Ethernet switches might only be able to support disabling
> multicast
>    snooping globally, which is an issue for example when several bridges
>    span the same physical device and request contradictory settings.
>       Propagate the return value of br_mc_disabled_update() such that this
>    limitation is transmitted correctly to user-space.
>       Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
>    Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> net/bridge/br_multicast.c | 28 +++++++++++++++++++++-------
> net/bridge/br_netlink.c   |  4 +++-
> net/bridge/br_private.h   |  3 ++-
> net/bridge/br_sysfs_br.c  |  8 +-------
> 4 files changed, 27 insertions(+), 16 deletions(-)
> 
> not sure if it matters this is on s390.
> A simple reproducer is virt-install, e.g.
> virt-install --name test --disk size=12 --memory=2048 --vcpus=2
> --location
> http://ports.ubuntu.com/ubuntu-ports/dists/bionic/main/installer-s390x/

Thanks, I will kick off a reproducer and let you know.
-- 
Florian

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: net: bridge: propagate error code and extack from br_mc_disabled_update
  2021-04-21 18:37     ` Florian Fainelli
@ 2021-04-21 18:46       ` Vladimir Oltean
  2021-04-21 18:54         ` Christian Borntraeger
  0 siblings, 1 reply; 7+ messages in thread
From: Vladimir Oltean @ 2021-04-21 18:46 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Christian Borntraeger, andrew, davem, idosch, jiri, kuba, netdev,
	nikolay, roopa, vladimir.oltean, linux-next, kvm list,
	linux-s390

On Wed, Apr 21, 2021 at 11:37:25AM -0700, Florian Fainelli wrote:
> On 4/21/2021 11:35 AM, Christian Borntraeger wrote:
> > On 21.04.21 20:18, Christian Borntraeger wrote:
> >> Whatever version landed in next, according to bisect this broke
> >> libvirt/kvms use of bridges:
> >>
> >>
> >> # virsh start s31128001
> >> error: Failed to start domain 's31128001'
> >> error: Unable to add bridge virbr1 port vnet0: Operation not supported
> >>
> >> # grep vnet0 /var/log/libvirt/libvirtd.log
> >>
> >> 2021-04-21 07:43:09.453+0000: 2460: info : virNetDevTapCreate:240 :
> >> created device: 'vnet0'
> >> 2021-04-21 07:43:09.453+0000: 2460: debug :
> >> virNetDevSetMACInternal:287 : SIOCSIFHWADDR vnet0
> >> MAC=fe:bb:83:28:01:02 - Success
> >> 2021-04-21 07:43:09.453+0000: 2460: error : virNetDevBridgeAddPort:633
> >> : Unable to add bridge virbr1 port vnet0: Operation not supported
> >> 2021-04-21 07:43:09.466+0000: 2543: debug : udevHandleOneDevice:1695 :
> >> udev action: 'add': /sys/devices/virtual/net/vnet0
> >>
> >> Christian
> >>
> > 
> > For reference:
> > 
> > ae1ea84b33dab45c7b6c1754231ebda5959b504c is the first bad commit
> > commit ae1ea84b33dab45c7b6c1754231ebda5959b504c
> > Author: Florian Fainelli <f.fainelli@gmail.com>
> > Date:   Wed Apr 14 22:22:57 2021 +0300
> > 
> >    net: bridge: propagate error code and extack from br_mc_disabled_update
> >       Some Ethernet switches might only be able to support disabling
> > multicast
> >    snooping globally, which is an issue for example when several bridges
> >    span the same physical device and request contradictory settings.
> >       Propagate the return value of br_mc_disabled_update() such that this
> >    limitation is transmitted correctly to user-space.
> >       Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> >    Signed-off-by: David S. Miller <davem@davemloft.net>
> > 
> > net/bridge/br_multicast.c | 28 +++++++++++++++++++++-------
> > net/bridge/br_netlink.c   |  4 +++-
> > net/bridge/br_private.h   |  3 ++-
> > net/bridge/br_sysfs_br.c  |  8 +-------
> > 4 files changed, 27 insertions(+), 16 deletions(-)
> > 
> > not sure if it matters this is on s390.
> > A simple reproducer is virt-install, e.g.
> > virt-install --name test --disk size=12 --memory=2048 --vcpus=2
> > --location
> > http://ports.ubuntu.com/ubuntu-ports/dists/bionic/main/installer-s390x/
> 
> Thanks, I will kick off a reproducer and let you know.
> -- 
> Florian

Hey, you guys are moving fast, faster than it took me to open my email client...

Sorry for the breakage, Christian, I've just sent a patch with what I
think is wrong, could you give it a try?

Thanks!

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: net: bridge: propagate error code and extack from br_mc_disabled_update
  2021-04-21 18:46       ` Vladimir Oltean
@ 2021-04-21 18:54         ` Christian Borntraeger
  0 siblings, 0 replies; 7+ messages in thread
From: Christian Borntraeger @ 2021-04-21 18:54 UTC (permalink / raw)
  To: Vladimir Oltean, Florian Fainelli
  Cc: andrew, davem, idosch, jiri, kuba, netdev, nikolay, roopa,
	vladimir.oltean, linux-next, kvm list, linux-s390



On 21.04.21 20:46, Vladimir Oltean wrote:
> On Wed, Apr 21, 2021 at 11:37:25AM -0700, Florian Fainelli wrote:
>> On 4/21/2021 11:35 AM, Christian Borntraeger wrote:
>>> On 21.04.21 20:18, Christian Borntraeger wrote:
>>>> Whatever version landed in next, according to bisect this broke
>>>> libvirt/kvms use of bridges:
>>>>
>>>>
>>>> # virsh start s31128001
>>>> error: Failed to start domain 's31128001'
>>>> error: Unable to add bridge virbr1 port vnet0: Operation not supported
>>>>
>>>> # grep vnet0 /var/log/libvirt/libvirtd.log
>>>>
>>>> 2021-04-21 07:43:09.453+0000: 2460: info : virNetDevTapCreate:240 :
>>>> created device: 'vnet0'
>>>> 2021-04-21 07:43:09.453+0000: 2460: debug :
>>>> virNetDevSetMACInternal:287 : SIOCSIFHWADDR vnet0
>>>> MAC=fe:bb:83:28:01:02 - Success
>>>> 2021-04-21 07:43:09.453+0000: 2460: error : virNetDevBridgeAddPort:633
>>>> : Unable to add bridge virbr1 port vnet0: Operation not supported
>>>> 2021-04-21 07:43:09.466+0000: 2543: debug : udevHandleOneDevice:1695 :
>>>> udev action: 'add': /sys/devices/virtual/net/vnet0
>>>>
>>>> Christian
>>>>
>>>
>>> For reference:
>>>
>>> ae1ea84b33dab45c7b6c1754231ebda5959b504c is the first bad commit
>>> commit ae1ea84b33dab45c7b6c1754231ebda5959b504c
>>> Author: Florian Fainelli <f.fainelli@gmail.com>
>>> Date:   Wed Apr 14 22:22:57 2021 +0300
>>>
>>>     net: bridge: propagate error code and extack from br_mc_disabled_update
>>>        Some Ethernet switches might only be able to support disabling
>>> multicast
>>>     snooping globally, which is an issue for example when several bridges
>>>     span the same physical device and request contradictory settings.
>>>        Propagate the return value of br_mc_disabled_update() such that this
>>>     limitation is transmitted correctly to user-space.
>>>        Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>>>     Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
>>>     Signed-off-by: David S. Miller <davem@davemloft.net>
>>>
>>> net/bridge/br_multicast.c | 28 +++++++++++++++++++++-------
>>> net/bridge/br_netlink.c   |  4 +++-
>>> net/bridge/br_private.h   |  3 ++-
>>> net/bridge/br_sysfs_br.c  |  8 +-------
>>> 4 files changed, 27 insertions(+), 16 deletions(-)
>>>
>>> not sure if it matters this is on s390.
>>> A simple reproducer is virt-install, e.g.
>>> virt-install --name test --disk size=12 --memory=2048 --vcpus=2
>>> --location
>>> http://ports.ubuntu.com/ubuntu-ports/dists/bionic/main/installer-s390x/
>>
>> Thanks, I will kick off a reproducer and let you know.
>> -- 
>> Florian
> 
> Hey, you guys are moving fast, faster than it took me to open my email client...
> 
> Sorry for the breakage, Christian, I've just sent a patch with what I
> think is wrong, could you give it a try?

Yes, this fixes the issue. I answered on the patch.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2021-04-21 18:54 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-14 19:22 [PATCH v2 net-next] net: bridge: propagate error code and extack from br_mc_disabled_update Vladimir Oltean
2021-04-14 21:40 ` patchwork-bot+netdevbpf
2021-04-21 18:18 ` Christian Borntraeger
2021-04-21 18:35   ` Christian Borntraeger
2021-04-21 18:37     ` Florian Fainelli
2021-04-21 18:46       ` Vladimir Oltean
2021-04-21 18:54         ` Christian Borntraeger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).