In a lot of places, we use this kind of comparison to detect if a
device has a lower link:
dev->ifindex != dev_get_iflink(dev)
This seems to be a leftover of the pre-netns days, when the ifindex
was unique over the whole system. Nowadays, with network namespaces,
it's very easy to create a device with the same ifindex as its lower
link:
ip netns add main
ip netns add peer
ip -net main link add dummy0 type dummy
ip -net main link add link dummy0 macvlan0 netns peer type macvlan
ip -net main link show type dummy
9: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop ...
ip -net peer link show type macvlan
9: macvlan0@if9: <BROADCAST,MULTICAST> mtu 1500 qdisc noop ...
To detect if a device has a lower link, we can simply check the
existence of the dev->netdev_ops->ndo_get_iflink operation, instead of
checking its return value. In particular, I attempted to fix one of
these checks in commit feadc4b6cf42 ("rtnetlink: always put IFLA_LINK
for links with a link-netnsid"), but this patch isn't correct, since
tunnel devices can export IFLA_LINK_NETNSID without IFLA_LINK. That
patch needs to be reverted.
This series will fix all those bogus comparisons, and export missing
IFLA_LINK_NETNSID attributes in bridge and ipv6 dumps.
ipvlan and geneve are also missing the get_link_net operation, so
userspace can't know when those device are cross-netns. There are a
couple of other device types that have an ndo_get_iflink op but no
get_link_net (virt_wifi, ipoib), and should probably also have a
get_link_net.
Sabrina Dubroca (12):
ipvlan: add get_link_net
geneve: add get_link_net
Revert "rtnetlink: always put IFLA_LINK for links with a link-netnsid"
rtnetlink: always put IFLA_LINK for links with ndo_get_iflink
bridge: always put IFLA_LINK for ports with ndo_get_iflink
bridge: advertise IFLA_LINK_NETNSID when dumping bridge ports
ipv6: always put IFLA_LINK for devices with ndo_get_iflink
ipv6: advertise IFLA_LINK_NETNSID when dumping ipv6 addresses
net: link_watch: fix operstate when the link has the same index as the
device
net: link_watch: fix detection of urgent events
batman-adv: fix iflink detection in batadv_is_on_batman_iface
batman-adv: fix detection of lower link in batadv_get_real_netdevice
drivers/net/can/vxcan.c | 2 +-
drivers/net/geneve.c | 8 ++++++++
drivers/net/ipvlan/ipvlan_main.c | 9 +++++++++
drivers/net/veth.c | 2 +-
include/net/rtnetlink.h | 4 ++++
net/batman-adv/hard-interface.c | 4 ++--
net/bridge/br_netlink.c | 4 +++-
net/core/link_watch.c | 4 ++--
net/core/rtnetlink.c | 25 ++++++++++++-------------
net/ipv6/addrconf.c | 11 ++++++++++-
10 files changed, 52 insertions(+), 21 deletions(-)
--
2.28.0
Linux 4.9.297 doesn't provide BUILD_BUG_ON anymore in linux/bug.h also
identified itself with the version number 4.9.255 when decoding the
LINUX_VERSION_CODE. So we have to try to guess now if we need to include
linux/build_bug.h based on whether BUILD_BUG_ON is defined or not after
including linux/bug.h.
If not doing this, the build will fail with errors like:
net/batman-adv/bat_algo.c:146:1: error: undefined identifier 'BUILD_BUG_ON_ZERO'
net/batman-adv/bat_algo.c:146:1: error: undefined identifier 'BUILD_BUG_ON_ZERO'
net/batman-adv/bat_algo.c:146:1: error: undefined identifier 'BUILD_BUG_ON_ZERO'
net/batman-adv/bat_algo.c:146:1: error: undefined identifier 'BUILD_BUG_ON_ZERO'
net/batman-adv/bat_algo.c:146:1: error: undefined identifier 'BUILD_BUG_ON_ZERO'
net/batman-adv/bat_algo.c:146:1: error: undefined identifier 'BUILD_BUG_ON_ZERO'
In file included from ./arch/x86/include/asm/cpufeatures.h:5,
from ./arch/x86/include/asm/cmpxchg.h:5,
from ./arch/x86/include/asm/atomic.h:7,
from ./include/linux/atomic.h:4,
from net/batman-adv/main.h:207,
from net/batman-adv/bat_algo.c:7:
./arch/x86/include/asm/qspinlock.h: In function ‘virt_spin_lock’:
./arch/x86/include/asm/required-features.h:104:29: error: implicit declaration of function ‘BUILD_BUG_ON_ZERO’ [-Werror=implicit-function-declaration]
Signed-off-by: Sven Eckelmann <sven(a)narfation.org>
---
compat-include/linux/build_bug.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/compat-include/linux/build_bug.h b/compat-include/linux/build_bug.h
index 0eecc688..1002431d 100644
--- a/compat-include/linux/build_bug.h
+++ b/compat-include/linux/build_bug.h
@@ -15,6 +15,17 @@
#include_next <linux/build_bug.h>
#else
#include <linux/bug.h>
+
+/* Linux 4.9.297 doesn't provide BUILD_BUG_ON anymore in linux/bug.h
+ * also identified itself with the version number 4.9.255 when decoding the
+ * LINUX_VERSION_CODE. So we have to try to guess now if we need to include
+ * linux/build_bug.h based on whether BUILD_BUG_ON is defined or not after
+ * including linux/bug.h
+ */
+#ifndef BUILD_BUG_ON
+#include_next <linux/build_bug.h>
+#endif
+
#endif
#endif /* _NET_BATMAN_ADV_COMPAT_LINUX_BUILD_BUG_H_ */
--
2.30.2
Hi,
alfred could be used without any interface at all and operate as local data
storage between 2 processes on the same system or the interface could be
configured at a later time (via unix socket).
To allow for these additional use cases and keep the current behavior, the
interface command line parameter shall accept 'none' as interface name
(similar to the batman-adv interface).
Cheers,
Marek
Hi,
the alfred daemon has built-in capabilities for accepting runtime
configuration. Network interfaces and alfred 'mode' (primary/secondary)
settings can be modified via instructions sent over unix socket.
To make all settings configurable, the unix socket commands are extended to
also support setting the batman-adv interface name at runtime. Network
interfaces should no longer be required at startup as those can be configured
at runtime.
All these runtime settings make understanding the current alfred configuration
tricky. Therefore, alfred should be able to export its operating configuration
via unix socket.
Cheers,
Marek