• Vladimir Oltean's avatar
    net: dsa: introduce locking for the address lists on CPU and DSA ports · d3bd8924
    Vladimir Oltean authored
    Now that the rtnl_mutex is going away for dsa_port_{host_,}fdb_{add,del},
    no one is serializing access to the address lists that DSA keeps for the
    purpose of reference counting on shared ports (CPU and cascade ports).
    
    It can happen for one dsa_switch_do_fdb_del to do list_del on a dp->fdbs
    element while another dsa_switch_do_fdb_{add,del} is traversing dp->fdbs.
    We need to avoid that.
    
    Currently dp->mdbs is not at risk, because dsa_switch_do_mdb_{add,del}
    still runs under the rtnl_mutex. But it would be nice if it would not
    depend on that being the case. So let's introduce a mutex per port (the
    address lists are per port too) and share it between dp->mdbs and
    dp->fdbs.
    
    The place where we put the locking is interesting. It could be tempting
    to put a DSA-level lock which still serializes calls to
    .port_fdb_{add,del}, but it would still not avoid concurrency with other
    driver code paths that are currently under rtnl_mutex (.port_fdb_dump,
    .port_fast_age). So it would add a very false sense of security (and
    adding a global switch-wide lock in DSA to resynchronize with the
    rtnl_lock is also counterproductive and hard).
    
    So the locking is intentionally done only where the dp->fdbs and dp->mdbs
    lists are traversed. That means, from a driver perspective, that
    .port_fdb_add will be called with the dp->addr_lists_lock mutex held on
    the CPU port, but not held on user ports. This is done so that driver
    writers are not encouraged to rely on any guarantee offered by
    dp->addr_lists_lock.
    Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    d3bd8924
switch.c 18.9 KB