[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210115171142.4iylui5uuv5vljwq@skbuf>
Date: Fri, 15 Jan 2021 19:11:42 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, alexandre.belloni@...tlin.com,
andrew@...n.ch, f.fainelli@...il.com, vivien.didelot@...il.com,
alexandru.marginean@....com, claudiu.manoil@....com,
xiaoliang.yang_1@....com, hongbo.wang@....com, jiri@...nulli.us,
idosch@...sch.org, UNGLinuxDriver@...rochip.com
Subject: Renaming interfaces that are up (Was "Re: [PATCH v3 net-next 08/10]
net: mscc: ocelot: register devlink") ports
On Thu, Jan 14, 2021 at 08:44:35AM -0800, Jakub Kicinski wrote:
> > > Can you unbind and bind the driver back and see if phys_port_name
> > > always gets the correct value? (replay/udevadm test is not sufficient)
> >
> > Yes, and that udev renaming test failed miserably still.
> >
> > I have dhcpcd in my system, and it races with my udev script by
> > auto-upping the interfaces when they probe. Then, dev_change_name()
> > returns -EBUSY because the interfaces are up but its priv_flags do not
> > declare IFF_LIVE_RENAME_OK.
> >
> > How is that one solved?
>
> Yeah, that's one of those perennial problems we never found a strong
> answer to. IIRC IFF_LIVE_RENAME_OK was more of a dirty hack than a
> serious answer. I think we should allow renaming interfaces while
> they're up, and see if anything breaks. We'd just need to add the right
> netlink notifications to dev_change_name(), maybe?
I'm probably crazy for even indulging in this, since it is likely going
to just be a huge time sink. But I need to ask anyway: what netlink
notification are you thinking of adding? Do you want me to call
dev_close and then dev_open, like what was discussed in the
"[virtio-dev] Re: net_failover slave udev renaming (was Re: [RFC PATCH
net-next v6 4/4] netvsc: refactor notifier/event handling code to use
the bypass framework)" thread and then in the "failover: allow name
change on IFF_UP slave interfaces" email threads?
By the way I removed the if condition and added nothing in its place,
just to see what would happen. I see a lot of these messages, I did not
investigate where they are coming from and why they are emitted. They go
away when I rename the interface back to swp0.
# ip monitor &
[1] 26931
# ip link set swp0 name random
[ 2857.570246] mscc_felix 0000:00:00.5 random: renamed from swp0
32: random: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default
link/ether 7a:1e:87:48:79:c0 brd ff:ff:ff:ff:ff:ff
Deleted inet swp0
inet swp0 forwarding off rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off
Deleted inet6 swp0
inet6 swp0 forwarding off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off
32: random: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default
link/ether 7a:1e:87:48:79:c0 brd ff:ff:ff:ff:ff:ff
fe80::/64 dev swp0 proto kernel metric 256 pref medium
32: swp0 inet6 fe80::e4fb:6ac5:7211:7981/64 scope link tentative
valid_lft forever preferred_lft forever
Deleted 32: swp0 inet6 fe80::e4fb:6ac5:7211:7981/64 scope link tentative
valid_lft forever preferred_lft forever
Deleted fe80::/64 dev swp0 proto kernel metric 256 pref medium
32: random: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default
link/ether 7a:1e:87:48:79:c0 brd ff:ff:ff:ff:ff:ff
fe80::/64 dev swp0 proto kernel metric 256 pref medium
32: swp0 inet6 fe80::e4fb:6ac5:7211:7981/64 scope link tentative
valid_lft forever preferred_lft forever
Deleted 32: swp0 inet6 fe80::e4fb:6ac5:7211:7981/64 scope link tentative
valid_lft forever preferred_lft forever
Deleted fe80::/64 dev swp0 proto kernel metric 256 pref medium
32: random: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default
link/ether 7a:1e:87:48:79:c0 brd ff:ff:ff:ff:ff:ff
fe80::/64 dev swp0 proto kernel metric 256 pref medium
32: swp0 inet6 fe80::e4fb:6ac5:7211:7981/64 scope link tentative
valid_lft forever preferred_lft forever
Deleted 32: swp0 inet6 fe80::e4fb:6ac5:7211:7981/64 scope link tentative
valid_lft forever preferred_lft forever
Deleted fe80::/64 dev swp0 proto kernel metric 256 pref medium
^C32: random: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default
link/ether 7a:1e:87:48:79:c0 brd ff:ff:ff:ff:ff:ff
fe80::/64 dev swp0 proto kernel metric 256 pref medium
32: swp0 inet6 fe80::e4fb:6ac5:7211:7981/64 scope link tentative
valid_lft forever preferred_lft forever
Deleted 32: swp0 inet6 fe80::e4fb:6ac5:7211:7981/64 scope link tentative
valid_lft forever preferred_lft forever
Deleted fe80::/64 dev swp0 proto kernel metric 256 pref medium
32: random: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default
link/ether 7a:1e:87:48:79:c0 brd ff:ff:ff:ff:ff:ff
fe80::/64 dev swp0 proto kernel metric 256 pref medium
32: swp0 inet6 fe80::e4fb:6ac5:7211:7981/64 scope link tentative
valid_lft forever preferred_lft forever
Deleted 32: swp0 inet6 fe80::e4fb:6ac5:7211:7981/64 scope link tentative
valid_lft forever preferred_lft forever
Deleted fe80::/64 dev swp0 proto kernel metric 256 pref medium
Powered by blists - more mailing lists