Skip to content
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

Merged
merged 6 commits into from
Dec 17, 2022

Conversation

enr0n
Copy link
Contributor

@enr0n enr0n commented Nov 1, 2022

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.

@github-actions github-actions bot added the udev label Nov 1, 2022
Copy link
Member

@yuwata yuwata left a 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.

src/udev/udev-event.c Outdated Show resolved Hide resolved
@yuwata yuwata added the reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks label Nov 1, 2022
@enr0n
Copy link
Contributor Author

enr0n commented Nov 1, 2022

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!

@enr0n enr0n force-pushed the nic-rename-fallback branch 2 times, most recently from fa6968f to caab516 Compare November 2, 2022 16:42
@enr0n
Copy link
Contributor Author

enr0n commented Nov 2, 2022

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.

@yuwata yuwata removed the reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks label Nov 2, 2022
@enr0n enr0n requested a review from yuwata November 7, 2022 15:51
src/udev/net/link-config.c Show resolved Hide resolved
@enr0n
Copy link
Contributor Author

enr0n commented Nov 16, 2022

I added a commit to skip setting old_name as an alternative name if the name_assign_type corresponding to old_name was NET_NAME_ENUM. I think this might be better than refusing names that start with eth, wlan, etc., but let me know if you still prefer that approach.

@enr0n enr0n requested a review from yuwata November 16, 2022 19:33
Copy link
Member

@yuwata yuwata left a 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.

src/libsystemd/sd-netlink/netlink-util.c Outdated Show resolved Hide resolved
src/libsystemd/sd-netlink/netlink-util.c Outdated Show resolved Hide resolved
@enr0n
Copy link
Contributor Author

enr0n commented Nov 23, 2022

I have made the changes you suggested, and I added some tests. Thanks!

@enr0n enr0n requested a review from yuwata November 23, 2022 20:41
@enr0n enr0n force-pushed the nic-rename-fallback branch 4 times, most recently from 779b90c to 9e72b37 Compare November 28, 2022 17:41
@yuwata yuwata removed the reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks label Nov 28, 2022
@yuwata yuwata added this to the v253 milestone Nov 28, 2022
@yuwata
Copy link
Member

yuwata commented Nov 30, 2022

Hmm, I am now confused.

If an interface foo has

Name=aaa
AlternativeNames=aaa bbb

Then, this PR makes the interface renamed to aaa with altnames foo and bbb. That's not expected.

@enr0n
Copy link
Contributor Author

enr0n commented Nov 30, 2022

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.

@enr0n
Copy link
Contributor Author

enr0n commented Dec 2, 2022

I pushed a version that does not ever swap old_name to an alternative name, as it seems this is not wanted in most cases. This approach would simplify things a bit.

I also added an additional commit that makes rename_netif() handle -EBUSY instead of avoiding the rename attempt if the device is already up, because it looks like that restriction will be removed in the mainline kernel soon (https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=bd039b5ea2a9).

@yuwata
Copy link
Member

yuwata commented Dec 7, 2022

@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.

@enr0n enr0n force-pushed the nic-rename-fallback branch 2 times, most recently from 74a12c3 to 3ca16af Compare December 7, 2022 22:32
@enr0n
Copy link
Contributor Author

enr0n commented Dec 7, 2022

For the test in systemd-networkd-tests.py, I just tried to cover some basic expectations for what happens when a device is renamed to a current alternative name. I couldn't think of a consistent way to trigger an error from there that would cause the rename to fail after deleting an alternative name. Let me know if that is OK or if you want something different from that test.

@keszybz keszybz added the please-review PR is ready for (re-)review by a maintainer label Dec 8, 2022
@enr0n
Copy link
Contributor Author

enr0n commented Dec 12, 2022

I think the jammy autopkgtest failures are test bed errors and unrelated.

Copy link
Member

@yuwata yuwata left a 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.

src/libsystemd/sd-netlink/netlink-util.c Outdated Show resolved Hide resolved
src/libsystemd/sd-netlink/netlink-util.c Outdated Show resolved Hide resolved
src/libsystemd/sd-netlink/test-netlink-util.c Outdated Show resolved Hide resolved
test/test-network/systemd-networkd-tests.py Outdated Show resolved Hide resolved
@yuwata yuwata added reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks and removed please-review PR is ready for (re-)review by a maintainer labels Dec 15, 2022
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().
@github-actions github-actions bot added please-review PR is ready for (re-)review by a maintainer and removed reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks labels Dec 15, 2022
@enr0n
Copy link
Contributor Author

enr0n commented Dec 15, 2022

Thanks for your review! I have addressed all comments in the latest push. PTAL.

@yuwata
Copy link
Member

yuwata commented Dec 15, 2022

LGTM. Thank you!

@yuwata yuwata added good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed and removed please-review PR is ready for (re-)review by a maintainer labels Dec 15, 2022
@enr0n
Copy link
Contributor Author

enr0n commented Dec 16, 2022

I think the jammy-ppc64el failure is unrelated; TEST-67-INTEGRITY is the failed test.

@bluca bluca merged commit 2c99e8c into systemd:main Dec 17, 2022
@keszybz keszybz removed the good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed label Dec 20, 2022
@keszybz
Copy link
Member

keszybz commented Feb 10, 2023

Queued up for v252.5. There was a trivial conflict.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

4 participants