On Thu, 14 Jan 2021 12:34:05 +0200 Vladimir Oltean wrote: > On Mon, Jan 11, 2021 at 11:19:09AM -0800, Jakub Kicinski wrote: > > > > devlink_port_attrs_set() should be called before netdev is registered, > > > > and devlink_port_type_eth_set() after. So this sequence makes me a tad > > > > suspicious. > > > > > > > > In particular IIRC devlink's .ndo_get_phys_port_name depends on it, > > > > because udev event needs to carry the right info for interface renaming > > > > to work reliably. No? > > > > > > If I change the driver's Kconfig from tristate to bool, all is fine, > > > isn't it? > > > > How does Kconfig change the order of registration of objects to > > subsystems _within_ the driver? > > The registration order within the driver is not what matters. What > matters is that the devlink_port and net_device are both registered > _before_ udev is up.
I see. > > 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?
