Re: [PATCH net-next] net: restore DSA behavior of not overriding ndo_get_phys_port_name if present

[Vladimir Oltean <olteanv@gmail.com>]

On Wed, Jul 22, 2020 at 03:11:09PM -0700, Florian Fainelli wrote:
> On 7/22/20 3:06 PM, Vladimir Oltean wrote:
> > On Wed, Jul 22, 2020 at 02:53:28PM -0700, Florian Fainelli wrote:
> >> On 7/22/20 1:53 PM, Vladimir Oltean wrote:
> >>> Prior to the commit below, dsa_master_ndo_setup() used to avoid
> >>> overriding .ndo_get_phys_port_name() unless the callback was empty.
> >>>
> >>> https://elixir.bootlin.com/linux/v5.7.7/source/net/dsa/master.c#L269
> >>>
> >>> Now, it overrides it unconditionally.
> >>>
> >>> This matters for boards where DSA switches are hanging off of other DSA
> >>> switches, or switchdev interfaces.
> >>> Say a user has these udev rules for the top-level switch:
> >>>
> >>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p0", NAME="swp0"
> >>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p1", NAME="swp1"
> >>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p2", NAME="swp2"
> >>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p3", NAME="swp3"
> >>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p4", NAME="swp4"
> >>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p5", NAME="swp5"
> >>>
> >>> If the DSA switches below start randomly overriding
> >>> ndo_get_phys_port_name with their own CPU port, bad things can happen.
> >>> Not only may the CPU port number be not unique among different
> >>> downstream DSA switches, but one of the upstream switchdev interfaces
> >>> may also happen to have a port with the same number. So, we may even end
> >>> up in a situation where all interfaces of the top-level switch end up
> >>> having a phys_port_name attribute of "p0". Clearly not ok if the purpose
> >>> of the udev rules is to assign unique names.
> >>>
> >>> Fix this by restoring the old behavior, which did not overlay this
> >>> operation on top of the DSA master logic, if there was one in place
> >>> already.
> >>>
> >>> Fixes: 3369afba1e46 ("net: Call into DSA netdevice_ops wrappers")
> >>> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
> >>> ---
> >>> This is brain-dead, please consider killing this and retrieving the CPU
> >>> port number from "devlink port"...
> >>
> >> That is fair enough. Do you want to submit such a change while you are
> >> at it?
> >>
> > 
> > If I'm getting you right, you mean I should be dropping this patch, and
> > send another one that deletes dsa_ndo_get_phys_port_name()?
> > I would expect that to be so - the problem is the fact that we're
> > retrieving the number of the CPU port through an ndo of the master
> > interface, it's not something we can fix by just calling into devlink
> > from kernel side. The user has to call into devlink.
> 
> Yes, that is what I meant, that an user should call the appropriate
> devlink command to obtain the port number, this particular change has
> caused more harm than good, and the justification for doing it in the
> first place was weak to begin with.
> -- 
> Florian

If the patch at this link is considered appropriate:
https://patchwork.ozlabs.org/project/netdev/patch/20200722224312.2719813-1-olteanv@gmail.com/
then this can be considered superseded by that.

If not, please apply this.

Thanks,
-Vladimir