• Marek Behún's avatar
    net: dsa: update the unicast MAC address when changing conduit · eef8e906
    Marek Behún authored
    When changing DSA user interface conduit while the user interface is up,
    DSA exhibits different behavior in comparison to when the interface is
    down. This different behavior concerns the primary unicast MAC address
    stored in the port standalone FDB and in the conduit device UC database.
    
    If we put a switch port down while changing the conduit with
      ip link set sw0p0 down
      ip link set sw0p0 type dsa conduit conduit1
      ip link set sw0p0 up
    we delete the address in dsa_user_close() and install the (possibly
    different) address in dsa_user_open().
    
    But when changing the conduit on the fly, the old address is not
    deleted and the new one is not installed.
    
    Since we explicitly want to support live-changing the conduit, uninstall
    the old address before calling dsa_port_assign_conduit() and install the
    (possibly different) new address after the call.
    
    Because conduit change might also trigger address change (the user
    interface is supposed to inherit the conduit interface MAC address if no
    address is defined in hardware (dp->mac is a zero address)), move the
    eth_hw_addr_inherit() call from dsa_user_change_conduit() to
    dsa_port_change_conduit(), just before installing the new address.
    
    Although this is in theory a flaw in DSA core, it needs not be
    backported, since there is currently no DSA driver that can be affected
    by this. The only DSA driver that supports changing conduit is felix,
    and, as explained by Vladimir Oltean [1]:
    
      There are 2 reasons why with felix the bug does not manifest itself.
    
      First is because both the 'ocelot' and the alternate 'ocelot-8021q'
      tagging protocols have the 'promisc_on_conduit = true' flag. So the
      unicast address doesn't have to be in the conduit's RX filter -
      neither the old or the new conduit.
    
      Second, dsa_user_host_uc_install() theoretically leaves behind host
      FDB entries installed towards the wrong (old) CPU port. But in
      felix_fdb_add(), we treat any FDB entry requested towards any CPU port
      as if it was a multicast FDB entry programmed towards _all_ CPU ports.
      For that reason, it is installed towards the port mask of the PGID_CPU
      port group ID:
    
    	if (dsa_port_is_cpu(dp))
    		port = PGID_CPU;
    
    Therefore no Fixes tag for this change.
    
    [1] https://lore.kernel.org/netdev/20240507201827.47suw4fwcjrbungy@skbuf/Signed-off-by: default avatarMarek Behún <kabel@kernel.org>
    Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
    Tested-by: default avatarVladimir Oltean <olteanv@gmail.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    eef8e906
user.h 1.99 KB