linux-kernel - Re: [PATCH net] i40e: Prevent unwanted interface name changes

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: <aKcr7FCOHZycDrsC@mozart.vkv.me>
Date: Thu, 21 Aug 2025 07:23:40 -0700
From: Calvin Owens <calvin@...nvd.org>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: Michal Schmidt <mschmidt@...hat.com>, netdev@...r.kernel.org,
	Tony Nguyen <anthony.l.nguyen@...el.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Jedrzej Jagielski <jedrzej.jagielski@...el.com>,
	Ivan Vecera <ivecera@...hat.com>, intel-wired-lan@...ts.osuosl.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] i40e: Prevent unwanted interface name changes

On Thursday 08/21 at 10:00 +0200, Przemek Kitszel wrote:
> On 8/20/25 19:41, Calvin Owens wrote:
> > On Wednesday 08/20 at 08:31 -0700, Calvin Owens wrote:
> > > On Wednesday 08/20 at 08:42 +0200, Michal Schmidt wrote:
> > > > On Wed, Aug 20, 2025 at 6:30 AM Calvin Owens <calvin@...nvd.org> wrote:
> > > > > The same naming regression which was reported in ixgbe and fixed in
> > > > > commit e67a0bc3ed4f ("ixgbe: prevent from unwanted interface name
> > > > > changes") still exists in i40e.
> > > > > 
> > > > > Fix i40e by setting the same flag, added in commit c5ec7f49b480
> > > > > ("devlink: let driver opt out of automatic phys_port_name generation").
> > > > > 
> > > > > Fixes: 9e479d64dc58 ("i40e: Add initial devlink support")
> > > > 
> > > > But this one's almost two years old. By now, there may be more users
> > > > relying on the new name than on the old one.
> > > > Michal
> > > 
> > > Well, I was relying on the new ixgbe names, and I had to revert them
> > > all in a bunch of configs yesterday after e67a0bc3ed4f :)
> 
> we have fixed (changed to old naming scheme) ixgbe right after the
> kernel was used by real users (modulo usual delay needed to invent
> a good solution)

No, the "fix" actually broke me for a *second time*, because I'd
already converted my infrastructure to use the *new* names, which match
i40e and the rest of the world.

We've seen *two* user ABI regressions in the last several months in
ixgbe now, both of which completely broke networking on the system.

I'm not here to whine about that: I just want to save as many people out
there in the real world as I can the trouble of having to do the same
work (which has absolutely no benefit) over the next five years in i40e.

If it's acceptable to break me for a second time to "fix" this, because
I'm the minority of users (a viewpoint I am in agreement with), it
should also be acceptable to break the minority of i40e users who are
running newer kernels to "fix" it there too.

Why isn't it?

> > 
> > And, even if it is e67a0bc3ed4f that introduced it, v6.7 was the first
> > release with it. I strongly suspect most servers with i40e NICs running
> > in the wild are running older kernels than that, and have not yet
> > encountered the naming regression. But you probably have much better
> > data about that than I do :)
> 
> RedHat patches their kernels with current code of the drivers that their
> customers use (including i40e and ixgbe)
> One could expect that changes made today to those will reach RHEL 10.3,
> even if it would be named "kernel 6.12".
> 
> (*) the changes will likely be also in 10.2, but I don't want to make
> any promises from Intel or Redhat here

But how many i40e users are actually on the most recent version of RHEL?
Not very many, is my guess. RHEL9 is 5.14, and has the old behavior.

If you actually have data on that, obviously that's different. But it
sounds like you're guessing just like I am.