Project

General

Profile

Actions
Copy link

Bug #423

closed

Moving a macvtap on top of batX to netns causes error

Added by Leonardo Mörlein about 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Sven Eckelmann
Target version:
2022.1
Start date:
02/26/2022
Due date:
% Done:

100%

Estimated time:

Description

Moving a macvtap interface on top of a batadv device into a netns causes an error. The following error is printed to dmesg:

[569490.277121] batman_adv: Cannot find parent device

The setup can be reproduced using the following script:

#!/bin/sh

# preparation
ip link add bat0 type batadv
ip link set bat0 up
ip netns add test
ip link add link bat0 name vtap type macvtap

# trigger the bug
ip link set vtap netns test up

# cleanup
ip netns exec test ip link del vtap
ip link del bat0
ip netns del test

I can reproduce this with:
  • 2021.3
  • 2022.0

I haven't checked other versions.

Actions
Copy link
 #1

Updated by Sven Eckelmann about 2 years ago

  • Status changed from New to Feedback
  • Assignee changed from batman-adv developers to Leonardo Mörlein

This message should just tell us that it was either not possible to get the correct parent net_namespace via rtnl or the parent dev via dev_get_iflink index (based on parent net_namespace). So the safety mechanism to prevent batman-adv over batman-adv is therefore disabled. But does it show any another kind of problems or only this message?

Actions
Copy link
 #2

Updated by Leonardo Mörlein about 2 years ago

I did not observe any other consequences.

If this is more or less just a warning, maybe the can be changed from loglevel "error" to loglevel "warning"?

For me, this is only a problem since its loglevel is "error". Since I regularly create macvtap devices and move them to network namespaces, this "error" occurs regularly for me and monitoring complains about it. While I could also just silence this error in the monitoring, it seems to me it might make sense to change the loglevel here? What do you think?

Actions
Copy link
 #3

Updated by Sven Eckelmann about 2 years ago

  • Status changed from Feedback to In Progress
  • Assignee changed from Leonardo Mörlein to Sven Eckelmann
  • Target version set to 2022.1

Yes, I would agree. But I would delay the submission of the mini patch (pr_err -> pr_warn + adjusted text) until I got all facts straight. This might sound a little bit strange but I have to write an acceptable commit message for the submission and there are also other people which wanted to change the way how this is handled. Which could mean that batman-adv needs other changes (but for some reason was forgotten)

I have now reproduced this problem with your script. View log...

I've added following small change to check the state:

diff --git a/net/batman-adv/hard-interface.c b/net/batman-adv/hard-interface.c
index 59d19097..eb62d426 100644
--- a/net/batman-adv/hard-interface.c
+++ b/net/batman-adv/hard-interface.c
@@ -162,6 +162,7 @@ static bool batadv_is_on_batman_iface(const struct net_device *net_dev)

     parent_net = batadv_getlink_net(net_dev, net);

+    printk("%p %d\n", parent_net, dev_get_iflink(net_dev));
     /* recurse over the parent device */
     parent_dev = __dev_get_by_index((struct net *)parent_net,
                     dev_get_iflink(net_dev));

The result was here:

[   50.293921][  T240] ffff88800cb00000 10

As you can see, the macvtap doesn't provide a way to figure out the link net but it returns an ifindex of 10 via its netdev_ops - which isn't valid in the "test" ns (which batman-adv uses as fallback in case the device itself returns the correct namespace of its link). The ifindex 10 btw. is bat0 in the init_net namespace:

root@node01:~# ip netns exec test ip link
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/gre 0.0.0.0 brd 0.0.0.0
3: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
4: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
5: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
11: vtap@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 500
    link/ether e6:b3:58:23:d7:e2 brd ff:ff:ff:ff:ff:ff

root@node01:~#  ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue master bat0 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 7a:62:40:45:d0:d3 brd ff:ff:ff:ff:ff:ff
3: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bat0 state UP mode DEFAULT group default qlen 1000
    link/ether 02:ba:de:af:fe:01 brd ff:ff:ff:ff:ff:ff
4: enp0s2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 06:ba:de:af:fe:01 brd ff:ff:ff:ff:ff:ff
5: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bat0 state UP mode DEFAULT group default qlen 1000
    link/ether 12:ba:de:af:fe:01 brd ff:ff:ff:ff:ff:ff
6: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/gre 0.0.0.0 brd 0.0.0.0
7: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
8: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
9: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
10: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether f2:b8:43:a3:75:7b brd ff:ff:ff:ff:ff:ff

I want to check if batman-adv is maybe not doing the checking correctly. But at least at the moment, it looks to me like rtnl (used by iproute2) is doing it similar (why it is shown in the iflink as "if10")

Actions
Copy link
 #5

Updated by Sven Eckelmann about 2 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 50 to 100

Both macvtap and batman-adv are now in the kernel. Following files are providing .ndo_get_iflink

  • drivers/infiniband/ulp/ipoib/ipoib_main.c
  • drivers/net/can/vxcan.c
  • drivers/net/ethernet/qualcomm/rmnet/rmnet_vnd.c
  • drivers/net/ipvlan/ipvlan_main.c
  • drivers/net/macsec.c
  • drivers/net/macvlan.c
  • drivers/net/veth.c
  • drivers/net/wireless/virt_wifi.c
  • net/8021q/vlan_dev.c
  • net/dsa/slave.c
  • net/ieee802154/6lowpan/core.c
  • net/ipv4/ip_gre.c

And following are providing .get_link_net

  • drivers/net/can/vxcan.c
  • drivers/net/ipvlan/ipvlan_main.c
  • drivers/net/macsec.c
  • drivers/net/macvlan.c
  • drivers/net/macvtap.c
  • drivers/net/ppp/ppp_generic.c
  • drivers/net/veth.c
  • drivers/net/vxlan.c
  • net/8021q/vlan_netlink.c
  • net/ipv4/ip_gre.c
  • net/ipv4/ip_vti.c
  • net/ipv4/ipip.c
  • net/ipv6/ip6_gre.c
  • net/ipv6/ip6_tunnel.c
  • net/ipv6/ip6_vti.c
  • net/ipv6/sit.c
  • net/xfrm/xfrm_interface.c
  • net/ipv4/ip_vti.c
  • net/ipv4/ipip.c
  • net/ipv4/ipmr.c
  • net/ipv6/ip6_gre.c
  • net/ipv6/ip6_tunnel.c
  • net/ipv6/ip6_vti.c
  • net/ipv6/ip6mr.c
  • net/ipv6/sit.c
  • net/xfrm/xfrm_interface.c

So there might be more devices types which have the same problem.

Actions
Copy link
 #6

Updated by Sven Eckelmann almost 2 years ago

  • Status changed from Resolved to Closed
Actions
Copy link

Also available in: Atom PDF