osmocom-net-gprs December 2024

osmocom-net-gprs@lists.osmocom.org

4 participants
6 discussions

RFC: unit tests for kernel GTP module
by Harald Welte 31 Dec '25

31 Dec '25

Dear GTP-interested folks, I would love to somehow get towards some degree of unit testing (or even "continuous integration") for teh kernel GTP code. We currently have the original code in the kernel, we had some recent small fixes and now are getting more patches into place. With relatively few active users out there (and probably none of them in production yet), it's particularly easy to introduce regressions while working on the code. Also, having tested new code even against a test set with limited covrage could help to get more confidence in new patches and thus get them merged sooner. Using tools like sgsnemu of OpenGGSN and the command line tools included in libgtpnl, it should be possibel to cook up some scripts for testing. Even the most basic set of tests would be an improvement over what we have now. One could also think about pcap replay to test with hand-crafted or real-world packets from other GTP implementations. As much as I'd like to put something like this into place myself, I don't think I will be able to work much on this in the near future. The GTP module at this point is a pure hobby and contrary to some years ago while I started it, I don't have any contract work in the GTP area at this point, so other projects currently unfortunately get more attention. So in case somebody among the GTP-interested parties (Travelping, OAI, ...) would want to do something in terms of testing, I'd be more than happy if somebody would step ahead. Otherwise it's all just vapourware going to end up on my ever-growing TODO list :/ Also, if netdev folks have some ideas/pointers about possible frameworks/tools for this kind of testing [it must exist for at least some other kernel networking code?]: Please let me know. I'd be interested to have a look if there's something that can be used as a basis (starting network namespaces, sending/transmitting packets, test case startup/teardown, ...) My "old school" approach would have been to start one or multiple user-mode-linux kernels (those that are to be tested), and then have scripts that set up a gtp socket and gtp tunnels via the libgtp command line tools, and throw packets at that. But I'm sure there must be quite powerful frameworks for that kind of testing in the 21st century? How do other tunneling implementations handle this? Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 5

[syzbot] [net?] possible deadlock in gtp_encap_enable_socket
by syzbot 12 May '25

12 May '25

Hello, syzbot found the following issue on: HEAD commit: 9410645520e9 Merge tag 'net-next-6.12' of git://git.kernel.. git tree: net-next console+strace: https://syzkaller.appspot.com/x/log.txt?x=15d39e9f980000 kernel config: https://syzkaller.appspot.com/x/.config?x=37c006d80708398d dashboard link: https://syzkaller.appspot.com/bug?extid=e953a8f3071f5c0a28fd compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16215ca9980000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=110c6c27980000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/80466d230dfb/disk-94106455.raw… vmlinux: https://storage.googleapis.com/syzbot-assets/ba253eabab42/vmlinux-94106455.… kernel image: https://storage.googleapis.com/syzbot-assets/569982fb6c88/bzImage-94106455.… IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+e953a8f3071f5c0a28fd(a)syzkaller.appspotmail.com IPVS: Unknown mcast interface: macvlan0 netlink: 8 bytes leftover after parsing attributes in process `syz-executor297'. netlink: 24 bytes leftover after parsing attributes in process `syz-executor297'. ====================================================== WARNING: possible circular locking dependency detected 6.11.0-syzkaller-01458-g9410645520e9 #0 Not tainted ------------------------------------------------------ syz-executor297/5243 is trying to acquire lock: ffff88801cf99158 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1609 [inline] ffff88801cf99158 (sk_lock-AF_INET){+.+.}-{0:0}, at: gtp_encap_enable_socket+0x2ce/0x5c0 drivers/net/gtp.c:1674 but task is already holding lock: ffffffff8fc88588 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock net/core/rtnetlink.c:79 [inline] ffffffff8fc88588 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x6e6/0xcf0 net/core/rtnetlink.c:6643 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (rtnl_mutex){+.+.}-{3:3}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5759 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 start_sync_thread+0xdc/0x2dc0 net/netfilter/ipvs/ip_vs_sync.c:1761 do_ip_vs_set_ctl+0x442/0x13d0 net/netfilter/ipvs/ip_vs_ctl.c:2732 nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101 smc_setsockopt+0x275/0xe50 net/smc/af_smc.c:3064 do_sock_setsockopt+0x3af/0x720 net/socket.c:2330 __sys_setsockopt+0x1ae/0x250 net/socket.c:2353 __do_sys_setsockopt net/socket.c:2362 [inline] __se_sys_setsockopt net/socket.c:2359 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2359 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #1 (&smc->clcsock_release_lock){+.+.}-{3:3}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5759 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 smc_switch_to_fallback+0x35/0xdb0 net/smc/af_smc.c:902 smc_sendmsg+0x11f/0x530 net/smc/af_smc.c:2771 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2603 ___sys_sendmsg net/socket.c:2657 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2686 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (sk_lock-AF_INET){+.+.}-{0:0}: check_prev_add kernel/locking/lockdep.c:3133 [inline] check_prevs_add kernel/locking/lockdep.c:3252 [inline] validate_chain+0x18e0/0x5900 kernel/locking/lockdep.c:3868 __lock_acquire+0x137a/0x2040 kernel/locking/lockdep.c:5142 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5759 lock_sock_nested+0x48/0x100 net/core/sock.c:3611 lock_sock include/net/sock.h:1609 [inline] gtp_encap_enable_socket+0x2ce/0x5c0 drivers/net/gtp.c:1674 gtp_encap_enable drivers/net/gtp.c:1707 [inline] gtp_newlink+0x589/0xf30 drivers/net/gtp.c:1511 rtnl_newlink_create net/core/rtnetlink.c:3510 [inline] __rtnl_newlink net/core/rtnetlink.c:3730 [inline] rtnl_newlink+0x1591/0x20a0 net/core/rtnetlink.c:3743 rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6646 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2603 ___sys_sendmsg net/socket.c:2657 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2686 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Chain exists of: sk_lock-AF_INET --> &smc->clcsock_release_lock --> rtnl_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(rtnl_mutex); lock(&smc->clcsock_release_lock); lock(rtnl_mutex); lock(sk_lock-AF_INET); *** DEADLOCK *** 1 lock held by syz-executor297/5243: #0: ffffffff8fc88588 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock net/core/rtnetlink.c:79 [inline] #0: ffffffff8fc88588 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x6e6/0xcf0 net/core/rtnetlink.c:6643 stack backtrace: CPU: 0 UID: 0 PID: 5243 Comm: syz-executor297 Not tainted 6.11.0-syzkaller-01458-g9410645520e9 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2186 check_prev_add kernel/locking/lockdep.c:3133 [inline] check_prevs_add kernel/locking/lockdep.c:3252 [inline] validate_chain+0x18e0/0x5900 kernel/locking/lockdep.c:3868 __lock_acquire+0x137a/0x2040 kernel/locking/lockdep.c:5142 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5759 lock_sock_nested+0x48/0x100 net/core/sock.c:3611 lock_sock include/net/sock.h:1609 [inline] gtp_encap_enable_socket+0x2ce/0x5c0 drivers/net/gtp.c:1674 gtp_encap_enable drivers/net/gtp.c:1707 [inline] gtp_newlink+0x589/0xf30 drivers/net/gtp.c:1511 rtnl_newlink_create net/core/rtnetlink.c:3510 [inline] __rtnl_newlink net/core/rtnetlink.c:3730 [inline] rtnl_newlink+0x1591/0x20a0 net/core/rtnetlink.c:3743 rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6646 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2603 ___sys_sendmsg net/socket.c:2657 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2686 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fed198844a9 Code: 48 83 c4 28 c3 e8 37 17 00 00 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 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RS --- 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. If the report is already addressed, let syzbot know by replying with: #syz fix: exact-commit-title If you want syzbot to run the reproducer, reply with: #syz test: git://repo/address.git branch-or-commit-hash If you attach or paste a git patch, syzbot will apply it before testing. If you want to overwrite report's subsystems, reply with: #syz set subsystems: new-subsystem (See the list of subsystem names on the web dashboard) If the report is a duplicate of another one, reply with: #syz dup: exact-subject-of-another-report If you want to undo deduplication, reply with: #syz undup

3 3

[PATCH net-next v6 00/11] net: Improve netns handling in rtnetlink
by Xiao Liang 18 Dec '24

18 Dec '24

This patch series includes some netns-related improvements and fixes for rtnetlink, to make link creation more intuitive: 1) Creating link in another net namespace doesn't conflict with link names in current one. 2) Refector rtnetlink link creation. Create link in target namespace directly. So that # ip link add netns ns1 link-netns ns2 tun0 type gre ... will create tun0 in ns1, rather than create it in ns2 and move to ns1. And don't conflict with another interface named "tun0" in current netns. Patch 01 servers for 1) to avoids link name conflict in different netns. To achieve 2), there're mainly 3 steps: - Patch 02 packs newlink() parameters into a struct, including the original "src_net" along with more netns context. - Patch 03 ~ 07 converts device drivers to use the explicit netns extracted from params. - Patch 08 ~ 09 removes the old netns parameter, and converts rtnetlink to create device in target netns directly. Patch 10 ~ 11 adds some tests for link name and link netns. BTW please note there're some issues found in current code: - In amt_newlink() drivers/net/amt.c: amt->net = net; ... amt->stream_dev = dev_get_by_index(net, ... Uses net, but amt_lookup_upper_dev() only searches in dev_net. So the AMT device may not be properly deleted if it's in a different netns from lower dev. - In gtp_newlink() in drivers/net/gtp.c: gtp->net = src_net; ... gn = net_generic(dev_net(dev), gtp_net_id); list_add_rcu(&gtp->list, &gn->gtp_dev_list); Uses src_net, but priv is linked to list in dev_net. So it may not be properly deleted on removal of link netns. - In pfcp_newlink() in drivers/net/pfcp.c: pfcp->net = net; ... pn = net_generic(dev_net(dev), pfcp_net_id); list_add_rcu(&pfcp->list, &pn->pfcp_dev_list); Same as above. - In lowpan_newlink() in net/ieee802154/6lowpan/core.c: wdev = dev_get_by_index(dev_net(ldev), nla_get_u32(tb[IFLA_LINK])); Looks for IFLA_LINK in dev_net, but in theory the ifindex is defined in link netns. --- v6: - Split prototype, driver and rtnetlink changes. - Add more tests for link netns. - Fix IPv6 tunnel net overwriten in ndo_init(). - Reorder variable declarations. - Exclude a ip_tunnel-specific patch. v5: link: https://lore.kernel.org/all/20241209140151.231257-1-shaw.leon@gmail.com/ - Fix function doc in batman-adv. - Include peer_net in rtnl newlink parameters. v4: link: https://lore.kernel.org/all/20241118143244.1773-1-shaw.leon@gmail.com/ - Pack newlink() parameters to a single struct. - Use ynl async_msg_queue.empty() in selftest. v3: link: https://lore.kernel.org/all/20241113125715.150201-1-shaw.leon@gmail.com/ - Drop "netns_atomic" flag and module parameter. Add netns parameter to newlink() instead, and convert drivers accordingly. - Move python NetNSEnter helper to net selftest lib. v2: link: https://lore.kernel.org/all/20241107133004.7469-1-shaw.leon@gmail.com/ - Check NLM_F_EXCL to ensure only link creation is affected. - Add self tests for link name/ifindex conflict and notifications in different netns. - Changes in dummy driver and ynl in order to add the test case. v1: link: https://lore.kernel.org/all/20241023023146.372653-1-shaw.leon@gmail.com/ Xiao Liang (11): rtnetlink: Lookup device in target netns when creating link rtnetlink: Pack newlink() params into struct net: Use link netns in newlink() of rtnl_link_ops ieee802154: 6lowpan: Use link netns in newlink() of rtnl_link_ops net: ip_tunnel: Use link netns in newlink() of rtnl_link_ops net: ipv6: Use link netns in newlink() of rtnl_link_ops net: xfrm: Use link netns in newlink() of rtnl_link_ops rtnetlink: Remove "net" from newlink params rtnetlink: Create link directly in target net namespace selftests: net: Add python context manager for netns entering selftests: net: Add test cases for link and peer netns drivers/infiniband/ulp/ipoib/ipoib_netlink.c | 11 +- drivers/net/amt.c | 16 +- drivers/net/bareudp.c | 11 +- drivers/net/bonding/bond_netlink.c | 8 +- drivers/net/can/dev/netlink.c | 4 +- drivers/net/can/vxcan.c | 9 +- .../ethernet/qualcomm/rmnet/rmnet_config.c | 11 +- drivers/net/geneve.c | 11 +- drivers/net/gtp.c | 9 +- drivers/net/ipvlan/ipvlan.h | 4 +- drivers/net/ipvlan/ipvlan_main.c | 15 +- drivers/net/ipvlan/ipvtap.c | 10 +- drivers/net/macsec.c | 15 +- drivers/net/macvlan.c | 8 +- drivers/net/macvtap.c | 11 +- drivers/net/netkit.c | 9 +- drivers/net/pfcp.c | 11 +- drivers/net/ppp/ppp_generic.c | 10 +- drivers/net/team/team_core.c | 7 +- drivers/net/veth.c | 9 +- drivers/net/vrf.c | 11 +- drivers/net/vxlan/vxlan_core.c | 11 +- drivers/net/wireguard/device.c | 11 +- drivers/net/wireless/virtual/virt_wifi.c | 14 +- drivers/net/wwan/wwan_core.c | 25 ++- include/net/ip_tunnels.h | 5 +- include/net/rtnetlink.h | 44 +++++- net/8021q/vlan_netlink.c | 15 +- net/batman-adv/soft-interface.c | 16 +- net/bridge/br_netlink.c | 12 +- net/caif/chnl_net.c | 6 +- net/core/rtnetlink.c | 35 +++-- net/hsr/hsr_netlink.c | 14 +- net/ieee802154/6lowpan/core.c | 9 +- net/ipv4/ip_gre.c | 27 ++-- net/ipv4/ip_tunnel.c | 10 +- net/ipv4/ip_vti.c | 10 +- net/ipv4/ipip.c | 14 +- net/ipv6/ip6_gre.c | 42 ++++-- net/ipv6/ip6_tunnel.c | 20 ++- net/ipv6/ip6_vti.c | 16 +- net/ipv6/sit.c | 18 ++- net/xfrm/xfrm_interface_core.c | 15 +- tools/testing/selftests/net/Makefile | 1 + .../testing/selftests/net/lib/py/__init__.py | 2 +- tools/testing/selftests/net/lib/py/netns.py | 18 +++ tools/testing/selftests/net/link_netns.py | 142 ++++++++++++++++++ tools/testing/selftests/net/netns-name.sh | 10 ++ 48 files changed, 546 insertions(+), 226 deletions(-) create mode 100755 tools/testing/selftests/net/link_netns.py -- 2.47.1

2 13

OUR NEW ORDER
by 領檯預約 18 Dec '24

18 Dec '24

Dear Sir, Please find attached requirement file for our Order . We wait for the invoice for payment Best Regards, Chin Mobile: + 86-15206165458 INCHON TEXTILE CO., LTD 3RD FLOOR,BUILDING #A,No.456, JINTANG WEST ROAD ZHANGJIAGANG CITY,JIANGSU PROVINCE, CHINA 张家港仁川纺织有限公司江苏张家港市金塘西路456号A幢3楼

1 0

Re: [PATCH net-next v5 5/5] selftests: net: Add two test cases for link netns
by Paolo Abeni 12 Dec '24

12 Dec '24

On 12/9/24 15:01, Xiao Liang wrote: > - Add test for creating link in another netns when a link of the same > name and ifindex exists in current netns. > - Add test for link netns atomicity - create link directly in target > netns, and no notifications should be generated in current netns. > > Signed-off-by: Xiao Liang <shaw.leon(a)gmail.com> > --- > tools/testing/selftests/net/Makefile | 1 + > tools/testing/selftests/net/netns-name.sh | 10 ++++++ > tools/testing/selftests/net/netns_atomic.py | 39 +++++++++++++++++++++ > 3 files changed, 50 insertions(+) > create mode 100755 tools/testing/selftests/net/netns_atomic.py > > diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile > index cb2fc601de66..f9f7a765d645 100644 > --- a/tools/testing/selftests/net/Makefile > +++ b/tools/testing/selftests/net/Makefile > @@ -34,6 +34,7 @@ TEST_PROGS += gre_gso.sh > TEST_PROGS += cmsg_so_mark.sh > TEST_PROGS += cmsg_time.sh cmsg_ipv6.sh > TEST_PROGS += netns-name.sh > +TEST_PROGS += netns_atomic.py > TEST_PROGS += nl_netdev.py > TEST_PROGS += srv6_end_dt46_l3vpn_test.sh > TEST_PROGS += srv6_end_dt4_l3vpn_test.sh > diff --git a/tools/testing/selftests/net/netns-name.sh b/tools/testing/selftests/net/netns-name.sh > index 6974474c26f3..0be1905d1f2f 100755 > --- a/tools/testing/selftests/net/netns-name.sh > +++ b/tools/testing/selftests/net/netns-name.sh > @@ -78,6 +78,16 @@ ip -netns $NS link show dev $ALT_NAME 2> /dev/null && > fail "Can still find alt-name after move" > ip -netns $test_ns link del $DEV || fail > > +# > +# Test no conflict of the same name/ifindex in different netns > +# > +ip -netns $NS link add name $DEV index 100 type dummy || fail > +ip -netns $NS link add netns $test_ns name $DEV index 100 type dummy || > + fail "Can create in netns without moving" > +ip -netns $test_ns link show dev $DEV >> /dev/null || fail "Device not found" > +ip -netns $NS link del $DEV || fail > +ip -netns $test_ns link del $DEV || fail > + > echo -ne "$(basename $0) \t\t\t\t" > if [ $RET_CODE -eq 0 ]; then > echo "[ OK ]" > diff --git a/tools/testing/selftests/net/netns_atomic.py b/tools/testing/selftests/net/netns_atomic.py > new file mode 100755 > index 000000000000..d350a3fc0a91 > --- /dev/null > +++ b/tools/testing/selftests/net/netns_atomic.py > @@ -0,0 +1,39 @@ > +#!/usr/bin/env python3 > +# SPDX-License-Identifier: GPL-2.0 > + > +import time > + > +from lib.py import ksft_run, ksft_exit, ksft_true > +from lib.py import ip > +from lib.py import NetNS, NetNSEnter > +from lib.py import RtnlFamily > + > + > +def test_event(ns1, ns2) -> None: > + with NetNSEnter(str(ns1)): > + rtnl = RtnlFamily() > + > + rtnl.ntf_subscribe("rtnlgrp-link") > + > + ip(f"netns set {ns1} 0", ns=str(ns2)) > + > + ip(f"link add netns {ns2} link-netnsid 0 dummy1 type dummy") > + ip(f"link add netns {ns2} dummy2 type dummy", ns=str(ns1)) > + > + ip("link del dummy1", ns=str(ns2)) > + ip("link del dummy2", ns=str(ns2)) > + > + time.sleep(1) > + rtnl.check_ntf() > + ksft_true(rtnl.async_msg_queue.empty(), > + "Received unexpected link notification") I think we need a much larger coverage here, possibly testing all the update drivers and more 'netns', 'link-netnsid', 'peer netns' permutations for the devices that allow them. Thanks, Paolo

2 1

[PATCH net-next v5 0/5] net: Improve netns handling in RTNL and ip_tunnel
by Xiao Liang 12 Dec '24

12 Dec '24

This patch series includes some netns-related improvements and fixes for RTNL and ip_tunnel, to make link creation more intuitive: - Creating link in another net namespace doesn't conflict with link names in current one. - Refector rtnetlink link creation. Create link in target namespace directly. Pass both source and link netns to drivers via newlink() callback. So that # ip link add netns ns1 link-netns ns2 tun0 type gre ... will create tun0 in ns1, rather than create it in ns2 and move to ns1. And don't conflict with another interface named "tun0" in current netns. --- v5: - Fix function doc in batman-adv. - Include peer_net in rtnl newlink parameters. v4: link: https://lore.kernel.org/all/20241118143244.1773-1-shaw.leon@gmail.com/ - Pack newlink() parameters to a single struct. - Use ynl async_msg_queue.empty() in selftest. v3: link: https://lore.kernel.org/all/20241113125715.150201-1-shaw.leon@gmail.com/ - Drop "netns_atomic" flag and module parameter. Add netns parameter to newlink() instead, and convert drivers accordingly. - Move python NetNSEnter helper to net selftest lib. v2: link: https://lore.kernel.org/all/20241107133004.7469-1-shaw.leon@gmail.com/ - Check NLM_F_EXCL to ensure only link creation is affected. - Add self tests for link name/ifindex conflict and notifications in different netns. - Changes in dummy driver and ynl in order to add the test case. v1: link: https://lore.kernel.org/all/20241023023146.372653-1-shaw.leon@gmail.com/ Xiao Liang (5): net: ip_tunnel: Build flow in underlay net namespace rtnetlink: Lookup device in target netns when creating link rtnetlink: Decouple net namespaces in rtnl_newlink_create() selftests: net: Add python context manager for netns entering selftests: net: Add two test cases for link netns drivers/infiniband/ulp/ipoib/ipoib_netlink.c | 11 +++-- drivers/net/amt.c | 13 +++--- drivers/net/bareudp.c | 11 +++-- drivers/net/bonding/bond_netlink.c | 8 ++-- drivers/net/can/dev/netlink.c | 4 +- drivers/net/can/vxcan.c | 9 ++-- .../ethernet/qualcomm/rmnet/rmnet_config.c | 11 +++-- drivers/net/geneve.c | 11 +++-- drivers/net/gtp.c | 9 ++-- drivers/net/ipvlan/ipvlan.h | 4 +- drivers/net/ipvlan/ipvlan_main.c | 11 +++-- drivers/net/ipvlan/ipvtap.c | 7 ++- drivers/net/macsec.c | 11 +++-- drivers/net/macvlan.c | 8 ++-- drivers/net/macvtap.c | 8 ++-- drivers/net/netkit.c | 9 ++-- drivers/net/pfcp.c | 8 ++-- drivers/net/ppp/ppp_generic.c | 10 +++-- drivers/net/team/team_core.c | 7 +-- drivers/net/veth.c | 9 ++-- drivers/net/vrf.c | 7 +-- drivers/net/vxlan/vxlan_core.c | 11 +++-- drivers/net/wireguard/device.c | 8 ++-- drivers/net/wireless/virtual/virt_wifi.c | 10 +++-- drivers/net/wwan/wwan_core.c | 15 +++++-- include/net/ip_tunnels.h | 5 ++- include/net/rtnetlink.h | 44 ++++++++++++++++--- net/8021q/vlan_netlink.c | 11 +++-- net/batman-adv/soft-interface.c | 12 ++--- net/bridge/br_netlink.c | 8 ++-- net/caif/chnl_net.c | 6 +-- net/core/rtnetlink.c | 35 ++++++++------- net/hsr/hsr_netlink.c | 14 +++--- net/ieee802154/6lowpan/core.c | 9 ++-- net/ipv4/ip_gre.c | 27 ++++++++---- net/ipv4/ip_tunnel.c | 16 ++++--- net/ipv4/ip_vti.c | 10 +++-- net/ipv4/ipip.c | 10 +++-- net/ipv6/ip6_gre.c | 28 +++++++----- net/ipv6/ip6_tunnel.c | 16 +++---- net/ipv6/ip6_vti.c | 15 +++---- net/ipv6/sit.c | 16 +++---- net/xfrm/xfrm_interface_core.c | 14 +++--- tools/testing/selftests/net/Makefile | 1 + .../testing/selftests/net/lib/py/__init__.py | 2 +- tools/testing/selftests/net/lib/py/netns.py | 18 ++++++++ tools/testing/selftests/net/netns-name.sh | 10 +++++ tools/testing/selftests/net/netns_atomic.py | 39 ++++++++++++++++ 48 files changed, 385 insertions(+), 211 deletions(-) create mode 100755 tools/testing/selftests/net/netns_atomic.py -- 2.47.1

2 6

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs December 2024