# Re: \[PATCH v3 net-next 7/9\] net: dsa: drop rtnl\_lock from dsa\_slave\_switchdev\_event\_work

- From: Florian Fainelli \<f.fainelli@gmail.com\>
- Date: 2021-10-22 17:37:29 
- List: netdev
- Page: https://ratatoskr.run/netdev/2021/10/11214224
- Thread: https://ratatoskr.run/netdev/2021/10/11214210/t.md

```text
On 10/22/21 10:27 AM, Vladimir Oltean wrote:
> 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
> c9eb3e0f8701 ("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
> b117e1e8a86d ("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: Vladimir Oltean <vladimir.oltean@nxp.com>

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian
```