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.
---
v4:
- 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 | 11 ++++--
.../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 | 11 ++++--
drivers/net/pfcp.c | 8 ++--
drivers/net/ppp/ppp_generic.c | 10 +++--
drivers/net/team/team_core.c | 7 ++--
drivers/net/veth.c | 11 ++++--
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 | 34 +++++++++++++---
net/8021q/vlan_netlink.c | 11 ++++--
net/batman-adv/soft-interface.c | 8 ++--
net/bridge/br_netlink.c | 8 ++--
net/caif/chnl_net.c | 6 +--
net/core/rtnetlink.c | 29 +++++++++-----
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, 377 insertions(+), 205 deletions(-)
create mode 100755 tools/testing/selftests/net/netns_atomic.py
--
2.47.0
Hi,
At Linux Plumbers, a few dozen of us gathered together to discuss how
to expose what tests subsystem maintainers would like to run for every
patch submitted or when CI runs tests. We agreed on a mock up of a
yaml template to start gathering info. The yaml file could be
temporarily stored on kernelci.org until a more permanent home could
be found. Attached is a template to start the conversation.
Longer story.
The current problem is CI systems are not unanimous about what tests
they run on submitted patches or git branches. This makes it
difficult to figure out why a test failed or how to reproduce.
Further, it isn't always clear what tests a normal contributor should
run before posting patches.
It has been long communicated that the tests LTP, xfstest and/or
kselftests should be the tests to run. However, not all maintainers
use those tests for their subsystems. I am hoping to either capture
those tests or find ways to convince them to add their tests to the
preferred locations.
The goal is for a given subsystem (defined in MAINTAINERS), define a
set of tests that should be run for any contributions to that
subsystem. The hope is the collective CI results can be triaged
collectively (because they are related) and even have the numerous
flakes waived collectively (same reason) improving the ability to
find and debug new test failures. Because the tests and process are
known, having a human help debug any failures becomes easier.
The plan is to put together a minimal yaml template that gets us going
(even if it is not optimized yet) and aim for about a dozen or so
subsystems. At that point we should have enough feedback to promote
this more seriously and talk optimizations.
Feedback encouraged.
Cheers,
Don
---
# List of tests by subsystem
#
# Tests should adhere to KTAP definitions for results
#
# Description of section entries
#
# maintainer: test maintainer - name <email>
# list: mailing list for discussion
# version: stable version of the test
# dependency: necessary distro package for testing
# test:
# path: internal git path or url to fetch from
# cmd: command to run; ability to run locally
# param: additional param necessary to run test
# hardware: hardware necessary for validation
#
# Subsystems (alphabetical)
KUNIT TEST:
maintainer:
- name: name1
email: email1
- name: name2
email: email2
list:
version:
dependency:
- dep1
- dep2
test:
- path: tools/testing/kunit
cmd:
param:
- path:
cmd:
param:
hardware: none