Re: [PATCH net-next] netdevsim: Register and unregister devlink traps on probe/remove device

On Wed, 27 Oct 2021 22:15:41 +0300 Leon Romanovsky wrote:

One of the outcomes is that such chain usually prevents from us to ensure
proper locking annotation.

Let's take as an example devlink_trap_policers_register().
In some drivers, it is called before device_register() and we don't need
any locks at all, because we are in initialization flow.

In mlxsw, it is called during devlink reload, and we don't really need to
lock it too, because we were supposed to lock everything for the reload.

However, for the mlxsw, we created devlink_trap_policers_register() to be
dynamic, so we must lock devlink->lock, as we don't know how other users
of this API will use it.

In the reality, no one uses it dynamically except mlxsw and we stuck
with function that calls to useless lock without us able to properly
annotate it with an invitation to misuse.

It is an example of layering problem, there are many more subtle issues
like this that require some cabal knowledge of proper locks to make it
is safe.

Now that you made me express my opinion I started feeling attached to
my way of thinking :) Let me try to convert devlink core, netdevsim and
nfp to devlink instance locking and see how far I can get...