On Wed, May 20, 2015 at 11:12 AM, Daniel Borkmann <dan...@iogearbox.net> wrote: > On 05/20/2015 07:38 PM, Cong Wang wrote: > ... >> >> Why synchronize_rcu() even matters here? It waits for >> readers, not for RCU callbacks. > > > Hm, I am mentioning it here as it was related to 78fd1d0ab072 > as explained in the commit message.
Move it to the right place or remove it, it is only confusing. > >>> Since we came here via unregister_tcf_proto_ops(), there >>> are no users of a given classifier anymore. Further nested >>> call_rcu()s pointing into the module space are not being >>> done anywhere. >> >> >> This doesn't look like the best way to fix it, since calling >> call_rcu() is tc filter specific, so why not just move the >> rcu_barrier() to each of the ->destroy() implementation? >> Let each filter handle its own implementation bug. > > > Effectively, every in-tree classifier (rsvp is the only exception) > is making use of call_rcu(). Moreover, moving this into every > ->destroy() handler would also be unnecessary overhead, imho, as > this is only relevant when we actually _unload_ a module. Well, ->destroy() is not a fast path, it holds rtnl lock, we don't want to lose readability for little performance gain. The code is hard to understand even with a comment there, move it to tcf_destroy() so that we probably don't even need a comment there. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
