On Mon, 2017-10-23 at 15:02 -0700, Cong Wang wrote: > b) As suggested by Paul, we could defer the work to a workqueue and > gain the permission of holding RTNL again without any performance > impact, however, this seems impossible too, because as lockdep > complains we have a deadlock when flushing workqueue while hodling > RTNL lock, see the rcu_barrier() in tcf_block_put(). > > Therefore, the simplest solution we have is probably just getting > rid of these RCU callbacks, because they are not necessary at all, > callers of these call_rcu() are all on slow paths and have RTNL > lock, so blocking is allowed in their contexts.
I am against these pessimistic changes, sorry for not following past discussions last week. I am asking a talk during upcoming netdev/netconf about this, if we need to take a decision. RTNL is already a big problem for many of us, adding synchronize_rcu() calls while holding RTNL is a no - go, unless we have clear evidence it can not be avoided. Thanks !
