linux-kernel - Re: Is it possible to undo the ixgbe device name change?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250424161059.2e85f8a0@kernel.org>
Date: Thu, 24 Apr 2025 16:10:59 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: David Howells <dhowells@...hat.com>, Jedrzej Jagielski
 <jedrzej.jagielski@...el.com>, Przemek Kitszel
 <przemyslaw.kitszel@...el.com>, Tony Nguyen <anthony.l.nguyen@...el.com>,
 Paulo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: Is it possible to undo the ixgbe device name change?

On Thu, 24 Apr 2025 23:32:12 +0200 Andrew Lunn wrote:
> > With commit:
> > 
> > 	a0285236ab93fdfdd1008afaa04561d142d6c276
> > 	ixgbe: add initial devlink support
> > 
> > the name of the device that I see on my 10G ethernet card changes from enp1s0
> > to enp1s0np0.  
> 
> Are you sure this patch is directly responsible? Looking at the patch
> i see:
> 
> @@ -11617,6 +11626,11 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
>         }
>         strcpy(netdev->name, "eth%d");
>         pci_set_drvdata(pdev, adapter);
> +
> +       devl_lock(adapter->devlink);
> +       ixgbe_devlink_register_port(adapter);
> +       SET_NETDEV_DEVLINK_PORT(adapter->netdev, &adapter->devlink_port);
> +
> 
> Notice the context, not the change. The interface is being called
> eth%d, which is normal. The kernel will replace the %d with a unique
> number. So the kernel will call it eth42 or something. You should see
> this in dmesg.
> 
> It is systemd which later renames it to enp1s0 or enp1s0np0. If you
> ask me, you are talking to the wrong people.

Hooking up the devlink port will add a suffix identifying the port,
it comes via dev_get_phys_port_name(). Intel could possibly implement
an empty ndo_get_phys_port_name to override. Tho, I do agree with you
in principle that this is highly unfortunate -- in principle _adding_
attributes should not cause regressions :(
Maybe NM could be thought to use altnames. But that's not a silver
bullet.