• Vladimir Oltean's avatar
    net: dsa: drop rtnl_lock from dsa_slave_switchdev_event_work · 5cdfde49
    Vladimir Oltean authored
    After talking with Ido Schimmel, it became clear that rtnl_lock is not
    actually required for anything that is done inside the
    SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE deferred work handlers.
    
    The reason why it was probably added by Arkadi Sharshevsky in commit
    c9eb3e0f ("net: dsa: Add support for learning FDB through
    notification") was to offer the same locking/serialization guarantees as
    .ndo_fdb_{add,del} and avoid reworking any drivers.
    
    DSA has implemented .ndo_fdb_add and .ndo_fdb_del until commit
    b117e1e8 ("net: dsa: delete dsa_legacy_fdb_add and
    dsa_legacy_fdb_del") - that is to say, until fairly recently.
    
    But those methods have been deleted, so now we are free to drop the
    rtnl_lock as well.
    
    Note that exposing DSA switch drivers to an unlocked method which was
    previously serialized by the rtnl_mutex is a potentially dangerous
    affair. Driver writers couldn't ensure that their internal locking
    scheme does the right thing even if they wanted.
    
    We could err on the side of paranoia and introduce a switch-wide lock
    inside the DSA framework, but that seems way overreaching. Instead, we
    could check as many drivers for regressions as we can, fix those first,
    then let this change go in once it is assumed to be fairly safe.
    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>
    5cdfde49
slave.c 66.7 KB