On Mon, Oct 23, 2017 at 4:16 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > 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.
So even Cc'ing you doesn't work. :-D > > I am asking a talk during upcoming netdev/netconf about this, if we need > to take a decision. I won't be able to make it. > > 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. You omitted too much, including the evidence I provide. In short it is very hard to do, otherwise I should have already done it. I am very open to any simple solution to avoid it, but so far none... Saying no but without giving a possible solution does not help anything here.
