-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
udev: set link alternative name if link is already up during rename #25221
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If an interface is configured with a .link file that contains the following:
[Link]
NamePolicy=path
AlternativeNamesPolicy=onboard
then, even if the AlternativeNamesPolicy=
does not have path
, the name based on the path may be set as an alternative name of the interface. I do not think it is expected.
That is a good point. I will address this. Thank you for reviewing! |
fa6968f
to
caab516
Compare
I have taken a different approach with the latest commits, which I believe addresses your concern regarding the alternative names policy, since it will only restore the alternative name if it was deleted. PTAL. |
caab516
to
b0d3385
Compare
I added a commit to skip setting |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add testcases for the change.
b0d3385
to
869ca90
Compare
I have made the changes you suggested, and I added some tests. Thanks! |
779b90c
to
9e72b37
Compare
Hmm, I am now confused. If an interface
Then, this PR makes the interface renamed to |
Yes, that is true. Can you please explain when you would expect the old name to be kept as an alternative name? I can see that this logic was introduced by 434a348, and reading the commit message, I understand why the new name must be removed if it is currently an alternative name. However, I do not understand why the old name is set as an alternative name in that case. |
9e72b37
to
f9c4bc1
Compare
I pushed a version that does not ever swap I also added an additional commit that makes |
f9c4bc1
to
ba32e5e
Compare
@enr0n Please (also?) implement a test in test/test-network/systemd-networkd-tests.py. If our CIs do not like the new test in C, then I think it is OK to drop it. |
74a12c3
to
3ca16af
Compare
For the test in |
I think the jammy autopkgtest failures are test bed errors and unrelated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly good. Several minor comments.
When configuring a link's alternative names, the link's new name to-be is not allowed to be included because interface renaming will fail if the new name is already present as an alternative name. However, rtnl_set_link_name will delete the conflicting alternative name before renaming the device, if necessary. Allow the new link name to be set as an alternative name before the device is renamed. This means that if the rename is later skipped (i.e. because the link is already up), then the name can at least still be present as an alternative name.
Commit 434a348 ("netlink: do not fail when new interface name is already used as an alternative name") added logic to set the old interface name as an alternative name, but only when the new name is currently an alternative name. This is not the desired outcome in most cases, and the important part of this commit was to delete the new name from the list of alternative names if necessary.
If a current alternative name is to be used to rename a network interface, the alternative name must be removed first. If interface renaming fails, restore the alternative name that was deleted if necessary.
Currently rename_netif() will not attempt to rename a device if it is already up, because the kernel will return -EBUSY unless live renaming is allowed on the device. This restriction will be removed in a future kernel version [1]. To cover both cases, always attempt to rename the interface and return 0 if we get -EBUSY. [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=bd039b5ea2a9
Add a test that verifies a deleted alternative name is restored on error in rtnl_set_link_name().
3ca16af
to
f68f644
Compare
Thanks for your review! I have addressed all comments in the latest push. PTAL. |
LGTM. Thank you! |
I think the jammy-ppc64el failure is unrelated; TEST-67-INTEGRITY is the failed test. |
Queued up for v252.5. There was a trivial conflict. |
The motivation for this PR is that in Ubuntu we have seen an issue similar to #15445, where udev's interface renaming of a subordinate device races with mlx5_core's own configuration.