On Thu, Feb 28, 2019 at 01:32:12AM -0800, si-wei liu wrote:

quoted

quoted

Will the
change break userspace further?

-Siwei

Didn't you show userspace is already broken. You can't "further
break it", rename already fails.

It's a race, userspace tends to give slave a user(space) desired name but
sometimes may fail due to this race. Today if failover master is not up,
rename would succeed anyway. While what you proposed prohibits user from
providing a name in all circumstances if I understand you correctly. That's
what I meant of breaking userspace further. On the other hand, you seem to
tighten the kernel default naming to udev predictable names, which is
derived from only recent systemd-udevd, while there exists many possible
userspace naming schemes out of that. Users today who deliberately chooses
to disable predictable naming (net.ifnames=0 biosdevname=0) and fall back to
kernel provided names would expect the ethX pattern, with this change
admin/user scripts which matches the ethX pattern could potentially break.

Whatever crashes with a name not matching ethX will crash on the
standby interface *anyway*.

So I think what you are saying is that someone might have already
written scripts and gotten them to work on v4.17 when STANDBY was
included and these scripts rely on ethX. Now these scripts
will break.

Maybe it is still early enough (just half a year passed) that the
number of these users would be small.  So how about a kernel config
option and maybe a module parameter to rename the primary?  People can
then opt in to the old broken behaviour.

-- 
MST