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
| ||
|
Date: Mon, 4 Apr 2022 14:31:15 +0200 From: Andrew Lunn <andrew@...n.ch> To: Ian Wienand <iwienand@...hat.com> Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net> Subject: Re: [PATCH] net/ethernet : set default assignment identifier to NET_NAME_ENUM On Mon, Apr 04, 2022 at 10:55:27AM +1000, Ian Wienand wrote: > On Sat, Apr 02, 2022 at 08:40:08PM +0200, Andrew Lunn wrote: > > So is there a risk here that Xen user suddenly find their network > > interfaces renamed, where as before they were not, and their > > networking thus breaks? > > Well, this is actually what "got" us. The interfaces *are* renamed on > CentOS 9-stream, but not on earlier releases, because systemd makes > different choices [1]. Tomorrow someone might "fix" something in that > systemd/udev chain that flips interfaces without specific use flags > back to not being renamed again. I'm certain it would vary based on > what distro and release you chose to boot. > > > Consistency is good, but it is hard to do in retrospect when there are > > deployed systems potentially dependent on the inconsistency. > > As noted, it is already the case that if your names are falling into > this path, they are unstable? (there are many pages for every distro > that go on and on about this, systemd/udev interactions, rules, link > files, and so on; e.g. [2]). > > I get what you are saying, that in a fixed virtual environment booting > some relatively fixed distro, perhaps the names are "stable enough" > and nobody has bothered updating this yet, so everyone is probably > happy enough with what they have. > > But ultimately it seems like nobody is regression testing this, and > all it takes is a seemingly unrelated change to struct layout or list > walking and things might change anyway. Then the answer would then be > -- well sorry about that but we never guaranteed that anyway. > > Reflecting reality and labeling the interface as named in a > unstable way just seems like the way forward here, to me. Hi Ian Please send a v2 and include this consideration in the commit message. It is then clear you have thought about the issue, why you think it is O.K, etc. We can then let others decide if it should be merged. If it does cause a regression and somebody thinks it should be reverted, your reasoning why it is O.K. is also easy to see etc. Andrew
Powered by blists - more mailing lists