[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 10 Oct 2023 14:10:03 +0200
From: Daniel Gröber <dxld@...kboxed.org>
To: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, Richard Weinberger <richard@....at>
Subject: [BUG] rtnl_newlink: Rogue MOVE event delivered on netns change
Hi netdev,
Changing a device's netns and renaming it with one RTM_NEWLINK call causes
a rogue MOVE uevent to be delivered to the new netns in addition to the
expected ADD uevent.
iproute2 reproducer:
$ ip netns add test
$ ip link add dev eth0 netns test type dummy
$ ip link add dev eth0 type dummy
$ ip -netns test link set dev eth0 netns 1 name eth123
With the last command, which renames the device and moves it out of the
netns, we get the following:
$ udevadm monitor -k
KERNEL[230953.424834] add /devices/virtual/net/eth0 (net)
KERNEL[230953.424914] move /devices/virtual/net/eth0 (net)
KERNEL[230953.425066] move /devices/virtual/net/eth123 (net)
The problem is the MOVE event hooribly confuses userspace. The particular
symptom we're seing is that systemd will bring down the ifup@...0.service
on the host as it handles the MOVE of eth0->eth123 as a stop for the
BoundTo sys-subsystem-net-devices-eth0.device unit.
I also create a clashing eth0 device on the host in the repro to
demonstrate that the RTM_NETLINK move+rename call is atomic and so the MOVE
event is entirely nonsensical.
Looking at the code in __rtnl_newlink I see do_setlink first calls
__dev_change_net_namespace and then dev_change_name. My guess is the order
is just wrong here.
Thanks,
--Daniel
PS: Full debugging log in https://github.com/lxc/incus/issues/146
Powered by blists - more mailing lists