B.A.T.M.A.N March 2021

b.a.t.m.a.n@lists.open-mesh.org

10 participants
12 discussions

[PATCH net 00/12] net: iflink and link-netnsid fixes
by Sabrina Dubroca 14 May '22

14 May '22

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

3 5

WARNING in sta_info_alloc
by syzbot 21 Jul '21

21 Jul '21

Hello, syzbot found the following issue on: HEAD commit: 549738f1 Linux 5.9-rc8 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=15b97ba3900000 kernel config: https://syzkaller.appspot.com/x/.config?x=c06bcf3cc963d91c dashboard link: https://syzkaller.appspot.com/bug?extid=45d7c243c006f39dc55a compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12bae9c0500000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1099b1c0500000 The issue was bisected to: commit 643c332d519bdfbf80d21f40d1c0aa0ccf3ec1cb Author: Zi Shen Lim <zlim.lnx(a)gmail.com> Date: Thu Jun 9 04:18:50 2016 +0000 arm64: bpf: optimize LD_ABS, LD_IND bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11d44477900000 final oops: https://syzkaller.appspot.com/x/report.txt?x=13d44477900000 console output: https://syzkaller.appspot.com/x/log.txt?x=15d44477900000 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+45d7c243c006f39dc55a(a)syzkaller.appspotmail.com Fixes: 643c332d519b ("arm64: bpf: optimize LD_ABS, LD_IND") ------------[ cut here ]------------ WARNING: CPU: 0 PID: 6879 at net/mac80211/ieee80211_i.h:1447 ieee80211_get_sband net/mac80211/ieee80211_i.h:1447 [inline] WARNING: CPU: 0 PID: 6879 at net/mac80211/ieee80211_i.h:1447 sta_info_alloc+0x1900/0x1f90 net/mac80211/sta_info.c:469 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 6879 Comm: syz-executor071 Not tainted 5.9.0-rc8-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x198/0x1fd lib/dump_stack.c:118 panic+0x382/0x7fb kernel/panic.c:231 __warn.cold+0x20/0x4b kernel/panic.c:600 report_bug+0x1bd/0x210 lib/bug.c:198 handle_bug+0x38/0x90 arch/x86/kernel/traps.c:234 exc_invalid_op+0x14/0x40 arch/x86/kernel/traps.c:254 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:536 RIP: 0010:ieee80211_get_sband net/mac80211/ieee80211_i.h:1447 [inline] RIP: 0010:sta_info_alloc+0x1900/0x1f90 net/mac80211/sta_info.c:469 Code: 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 f0 04 00 00 49 8b 9f 60 01 00 00 e9 fc f6 ff ff e8 80 20 b6 f9 <0f> 0b e8 e9 62 66 00 31 ff 89 c3 89 c6 e8 ce 1c b6 f9 85 db 74 1d RSP: 0018:ffffc9000539f498 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffffffff87c01d61 RDX: ffff8880a91ec3c0 RSI: ffffffff87c01e10 RDI: 0000000000000005 RBP: ffff8880896e0c80 R08: 0000000000000001 R09: ffffffff8d0c29e7 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880896e31b0 R14: dffffc0000000000 R15: ffff888092f06000 ieee80211_add_station+0x28c/0x660 net/mac80211/cfg.c:1586 rdev_add_station net/wireless/rdev-ops.h:190 [inline] nl80211_new_station+0xde7/0x1440 net/wireless/nl80211.c:6294 genl_family_rcv_msg_doit net/netlink/genetlink.c:669 [inline] genl_family_rcv_msg net/netlink/genetlink.c:714 [inline] genl_rcv_msg+0x61d/0x980 net/netlink/genetlink.c:731 netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2470 genl_rcv+0x24/0x40 net/netlink/genetlink.c:742 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:671 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2353 ___sys_sendmsg+0xf3/0x170 net/socket.c:2407 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x441999 Code: e8 dc 05 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b 0d fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffd9fa54bf8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000441999 RDX: 0000000000000000 RSI: 0000000020000040 RDI: 0000000000000005 RBP: 000000306e616c77 R08: 0000000000000000 R09: 0000002000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000032 R13: 0000000000000000 R14: 000000000000000c R15: 0000000000000004 Kernel Offset: disabled Rebooting in 86400 seconds.. --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. For information about bisection process see: https://goo.gl/tpsmEJ#bisection syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches

3 3

Re: [syzbot] WARNING in ieee802154_del_seclevel
by syzbot 31 Mar '21

31 Mar '21

syzbot has bisected this issue to: commit 416dacb819f59180e4d86a5550052033ebb6d72c Author: Alan Stern <stern(a)rowland.harvard.edu> Date: Wed Aug 21 17:27:12 2019 +0000 HID: hidraw: Fix invalid read in hidraw_ioctl bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=127430fcd00000 start commit: 6e5a03bc ethernet/netronome/nfp: Fix a use after free in n.. git tree: net final oops: https://syzkaller.appspot.com/x/report.txt?x=117430fcd00000 console output: https://syzkaller.appspot.com/x/log.txt?x=167430fcd00000 kernel config: https://syzkaller.appspot.com/x/.config?x=daeff30c2474a60f dashboard link: https://syzkaller.appspot.com/bug?extid=fbf4fc11a819824e027b syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13bfe45ed00000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1188e31ad00000 Reported-by: syzbot+fbf4fc11a819824e027b(a)syzkaller.appspotmail.com Fixes: 416dacb819f5 ("HID: hidraw: Fix invalid read in hidraw_ioctl") For information about bisection process see: https://goo.gl/tpsmEJ#bisection

1 0

Batman adv selective broadcast mechanism
by oytunyapar＠hotmail.com 31 Mar '21

31 Mar '21

Hi everybody, As I check, batman-adv protocol, sends IP broadcast packets, to every slave interface, including the slave interface from which the broadcast packet is received. Is there any way for preventing the batman-adv from sending IP broadcast packets to some of the slave interfaces (etc. the one which the packet is received)? Regards. Oytun

2 4

[PATCH net-next v3 0/7] mld: change context from atomic to sleepable
by Taehee Yoo 30 Mar '21

30 Mar '21

This patchset changes the context of MLD module. Before this patchset, MLD functions are atomic context so it couldn't use sleepable functions and flags. There are several reasons why MLD functions are under atomic context. 1. It uses timer API. Timer expiration functions are executed in the atomic context. 2. atomic locks MLD functions use rwlock and spinlock to protect their own resources. So, in order to switch context, this patchset converts resources to use RCU and removes atomic locks and timer API. 1. The first patch convert from the timer API to delayed work. Timer API is used for delaying some works. MLD protocol has a delay mechanism, which is used for replying to a query. If a listener receives a query from a router, it should send a response after some delay. But because of timer expire function is executed in the atomic context, this patch convert from timer API to the delayed work. 2. The fourth patch deletes inet6_dev->mc_lock. The mc_lock has protected inet6_dev->mc_tomb pointer. But this pointer is already protected by RTNL and it isn't be used by datapath. So, it isn't be needed and because of this, many atomic context critical sections are deleted. 3. The fifth patch convert ip6_sf_socklist to RCU. ip6_sf_socklist has been protected by ipv6_mc_socklist->sflock(rwlock). But this is already protected by RTNL So if it is converted to use RCU in order to be used in the datapath, the sflock is no more needed. So, its control path context can be switched to sleepable. 4. The sixth patch convert ip6_sf_list to RCU. The reason for this patch is the same as the previous patch. 5. The seventh patch convert ifmcaddr6 to RCU. The reason for this patch is the same as the previous patch. 6. Add new workqueues for processing query/report event. By this patch, query and report events are processed by workqueue So context is sleepable, not atomic. While this logic, it acquires RTNL. 7. Add new mc_lock. The purpose of this lock is to protect per-interface mld data. Per-interface mld data is usually used by query/report event handler. So, query/report event workers need only this lock instead of RTNL. Therefore, it could reduce bottleneck. Changelog: v2 -> v3: 1. Do not use msecs_to_jiffies(). (by Cong Wang) 2. Do not add unnecessary rtnl_lock() and rtnl_unlock(). (by Cong Wang) 3. Fix sparse warnings because of rcu annotation. (by kernel test robot) - Remove some rcu_assign_pointer(), which was used for non-rcu pointer. - Add union for rcu pointer. - Use rcu API in mld_clear_zeros(). - Remove remained rcu_read_unlock(). - Use rcu API for tomb resources. 4. withdraw prevopus 2nd and 3rd patch. - "separate two flags from ifmcaddr6->mca_flags" - "add a new delayed_work, mc_delrec_work" 5. Add 6th and 7th patch. v1 -> v2: 1. Withdraw unnecessary refactoring patches. (by Cong Wang, Eric Dumazet, David Ahern) a) convert from array to list. b) function rename. 2. Separate big one patch into small several patches. 3. Do not rename 'ifmcaddr6->mca_lock'. In the v1 patch, this variable was changed to 'ifmcaddr6->mca_work_lock'. But this is actually not needed. 4. Do not use atomic_t for 'ifmcaddr6->mca_sfcount' and 'ipv6_mc_socklist'->sf_count'. 5. Do not add mld_check_leave_group() function. 6. Do not add ip6_mc_del_src_bulk() function. 7. Do not add ip6_mc_add_src_bulk() function. 8. Do not use rcu_read_lock() in the qeth_l3_add_mcast_rtnl(). (by Julian Wiedmann) Taehee Yoo (7): mld: convert from timer to delayed work mld: get rid of inet6_dev->mc_lock mld: convert ipv6_mc_socklist->sflist to RCU mld: convert ip6_sf_list to RCU mld: convert ifmcaddr6 to RCU mld: add new workqueues for process mld events mld: add mc_lock for protecting per-interface mld data drivers/s390/net/qeth_l3_main.c | 6 +- include/net/if_inet6.h | 37 +- include/net/mld.h | 3 + net/batman-adv/multicast.c | 6 +- net/ipv6/addrconf.c | 9 +- net/ipv6/addrconf_core.c | 2 +- net/ipv6/af_inet6.c | 2 +- net/ipv6/icmp.c | 4 +- net/ipv6/mcast.c | 1080 ++++++++++++++++++------------- 9 files changed, 678 insertions(+), 471 deletions(-) -- 2.17.1

2 13

Problem with batman-adv and wifi adhoc in OpenWrt 19.07
by spiccinini＠altermundi.net 27 Mar '21

27 Mar '21

Hi all! I need some help debugging a non working setup of batman-adv with wifi in adhoc mode in OpenWrt 19.07 (a LibreMesh setup). Libremesh based on OpenWrt 19.07 + ad-hoc: not working Libremesh based on OpenWrt 19.07 + 802.11s: working Libremesh based on OpenWrt 18.06 + ad-hoc: working Libremesh based on OpenWrt 18.06 + 802.11s: working An issue with more info is here https://github.com/libremesh/lime-packages/issues/855 Thanks! SAn

2 2

[PATCH] batman-adv: Drop unused header preempt.h
by Sven Eckelmann 23 Mar '21

23 Mar '21

The commit 05456871ea96 ("batman-adv: Use netif_rx_any_context().") removed the last user for a function declaration from linux/preempt.h. The include should therefore be cleaned up. Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- net/batman-adv/bridge_loop_avoidance.c | 1 - 1 file changed, 1 deletion(-) diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c index bcd543ce..7dc133cf 100644 --- a/net/batman-adv/bridge_loop_avoidance.c +++ b/net/batman-adv/bridge_loop_avoidance.c @@ -25,7 +25,6 @@ #include <linux/lockdep.h> #include <linux/netdevice.h> #include <linux/netlink.h> -#include <linux/preempt.h> #include <linux/rculist.h> #include <linux/rcupdate.h> #include <linux/skbuff.h> -- 2.30.2

1 0

[PATCH maint] batman-adv: Fix order of kernel doc in batadv_priv
by Linus Lüssing 23 Mar '21

23 Mar '21

During the inlining process of kerneldoc some comments were placed at the wrong struct members. Fixing this by reordering the comments. Fixes: 6369b8e999af ("batman-adv: Use inline kernel-doc for enum/struct") Signed-off-by: Linus Lüssing <linus.luessing(a)c0d3.blue> --- Note: checkpatch shows me a warning: ``` ~/dev-priv/linux/linux/scripts/checkpatch.pl --strict ./0001-batman-adv-Fix-order-of-kernel-doc-in-batadv_priv.patch CHECK: spinlock_t definition without comment #35: FILE: net/batman-adv/types.h:1665: + spinlock_t forw_bat_list_lock; CHECK: spinlock_t definition without comment #39: FILE: net/batman-adv/types.h:1668: + spinlock_t forw_bcast_list_lock; total: 0 errors, 0 warnings, 2 checks, 25 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. ./0001-batman-adv-Fix-order-of-kernel-doc-in-batadv_priv.patch has style problems, please review. ``` However it seems to be a false positive: ``` ~/dev-priv/linux/linux/scripts/checkpatch.pl -f ./net/batman-adv/types.h Traceback (most recent call last): File "scripts/spdxcheck.py", line 10, in <module> import git ImportError: No module named git total: 0 errors, 0 warnings, 2410 lines checked NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. ./net/batman-adv/types.h has no obvious style problems and is ready for submission. ``` Checkpatch version is: e0c755a45f6f from net-master net/batman-adv/types.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/net/batman-adv/types.h b/net/batman-adv/types.h index 2f96e96a..30c78e6e 100644 --- a/net/batman-adv/types.h +++ b/net/batman-adv/types.h @@ -1658,19 +1658,19 @@ struct batadv_priv { /** @tp_list: list of tp sessions */ struct hlist_head tp_list; - /** @tp_num: number of currently active tp sessions */ - struct batadv_hashtable *orig_hash; - /** @orig_hash: hash table containing mesh participants (orig nodes) */ - spinlock_t forw_bat_list_lock; + struct batadv_hashtable *orig_hash; /** @forw_bat_list_lock: lock protecting forw_bat_list */ - spinlock_t forw_bcast_list_lock; + spinlock_t forw_bat_list_lock; /** @forw_bcast_list_lock: lock protecting forw_bcast_list */ - spinlock_t tp_list_lock; + spinlock_t forw_bcast_list_lock; /** @tp_list_lock: spinlock protecting @tp_list */ + spinlock_t tp_list_lock; + + /** @tp_num: number of currently active tp sessions */ atomic_t tp_num; /** @orig_work: work queue callback item for orig node purging */ -- 2.30.1

1 0

Neighbor and originator purge timeout
by oytunyapar＠hotmail.com 17 Mar '21

17 Mar '21

Hi everybody, As I checked from source code, BATADV_PURGE_TIMEOUT value determines: 1- When a node will be discarded from the neighbor list, if this particular node did not send ELP messages for BATADV_PURGE_TIMEOUT amount of time 2- When a node will be discarded from the originator list, if this particular node did not send OMG messages for 2 * BATADV_PURGE_TIMEOUT amount of time BATADV_PURGE_TIMEOUT is constant, and determined in compile time. It seem, it could not be configured via "batctl" utility. Am I correct? Regards. Oytun

1 0

batman-adv for kbit level speeds, external neighbor info
by oytunyapar＠hotmail.com 17 Mar '21

17 Mar '21

Hi everybody, I have some questions about batman-adv. Do you suggest, batman-adv, for speeds like 2.4kbit/s (very slow networks)? I tried to use batctl throughput_override, for such a setup. It seems at least 100kbit/s speed is valid for this utility. Is there any way, feeding neighbor information to batman-adv externally (etc. using DLEP protocol, as an external link monitor)? Thank you in advance. Regards. Oytun

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N March 2021