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: Wed, 22 Jul 2020 15:54:23 -0700 From: Florian Fainelli <f.fainelli@...il.com> To: Vladimir Oltean <olteanv@...il.com>, kuba@...nel.org, davem@...emloft.net, netdev@...r.kernel.org Cc: andrew@...n.ch, vivien.didelot@...il.com, jiri@...lanox.com, edumazet@...gle.com, ap420073@...il.com, xiyou.wangcong@...il.com, maximmi@...lanox.com, mkubecek@...e.cz, richardcochran@...il.com Subject: Re: [PATCH net-next] net: dsa: stop overriding master's ndo_get_phys_port_name On 7/22/20 3:43 PM, Vladimir Oltean wrote: > The purpose of this override is to give the user an indication of what > the number of the CPU port is (in DSA, the CPU port is a hardware > implementation detail and not a network interface capable of traffic). > > However, it has always failed (by design) at providing this information > to the user in a reliable fashion. > > Prior to commit 3369afba1e46 ("net: Call into DSA netdevice_ops > wrappers"), the behavior was to only override this callback if it was > not provided by the DSA master. > > That was its first failure: if the DSA master itself was a DSA port or a > switchdev, then the user would not see the number of the CPU port in > /sys/class/net/eth0/phys_port_name, but the number of the DSA master > port within its respective physical switch. > > But that was actually ok in a way. The commit mentioned above changed > that behavior, and now overrides the master's ndo_get_phys_port_name > unconditionally. That comes with problems of its own, which are worse in > a way. > > The idea is that it's typical for switchdev users to have udev rules for > consistent interface naming. These are based, among other things, on > the phys_port_name attribute. If we let the DSA switch at the bottom > to start randomly overriding ndo_get_phys_port_name with its own CPU > port, we basically lose any predictability in interface naming, or even > uniqueness, for that matter. > > So, there are reasons to let DSA override the master's callback (to > provide a consistent interface, a number which has a clear meaning and > must not be interpreted according to context), and there are reasons to > not let DSA override it (it breaks udev matching for the DSA master). > > But, there is an alternative method for users to retrieve the number of > the CPU port of each DSA switch in the system: > > $ devlink port > pci/0000:00:00.5/0: type eth netdev swp0 flavour physical port 0 > pci/0000:00:00.5/2: type eth netdev swp2 flavour physical port 2 > pci/0000:00:00.5/4: type notset flavour cpu port 4 > spi/spi2.0/0: type eth netdev sw0p0 flavour physical port 0 > spi/spi2.0/1: type eth netdev sw0p1 flavour physical port 1 > spi/spi2.0/2: type eth netdev sw0p2 flavour physical port 2 > spi/spi2.0/4: type notset flavour cpu port 4 > spi/spi2.1/0: type eth netdev sw1p0 flavour physical port 0 > spi/spi2.1/1: type eth netdev sw1p1 flavour physical port 1 > spi/spi2.1/2: type eth netdev sw1p2 flavour physical port 2 > spi/spi2.1/3: type eth netdev sw1p3 flavour physical port 3 > spi/spi2.1/4: type notset flavour cpu port 4 > > So remove this duplicated, unreliable and troublesome method. From this > patch on, the phys_port_name attribute of the DSA master will only > contain information about itself (if at all). If the users need reliable > information about the CPU port they're probably using devlink anyway. > > Signed-off-by: Vladimir Oltean <olteanv@...il.com> Acked-by: florian Fainelli <f.fainelli@...il.com> Thanks -- Florian
Powered by blists - more mailing lists