On Thu, Mar 26, 2015 at 3:17 PM, Alexander Duyck
[off-list ref] wrote:

On 03/26/2015 02:55 PM, Cong Wang wrote:

quoted

On Thu, Mar 26, 2015 at 2:47 PM, Alexander Duyck
[off-list ref] wrote:

quoted

I kind of think the patch title is misleading.  The code was already
under
an rtnl_lock, the problem was it was wrapped in the rules_mod_lock and
that

I don't see callers like ipmr_rules_exit() holds a rtnl lock.

It doesn't matter since ipmr is using a different set of fib_rules_ops.  So
for example it doesn't appear to implement a delete so all it is doing is
dropping the rules.  That is why fib_rules_cleanup_ops needs to stay within
the rules_mod_lock.

Why ops->delete() matters here since ops->rules_list is generic?

Rules are added to or deleted from ops->rules_list with rtnl lock,
so why it is safe to clean up them all without rtnl lock?

On the other hand, the name rules_mod_lock already tells it is
just a protection for ops (module) register.