From: Jon M. <jm...@re...> - 2020-05-22 21:37:43
|
On 5/22/20 4:10 PM, Eric Dumazet wrote: > > On 5/22/20 12:47 PM, Jon Maloy wrote: >> >> On 5/22/20 11:57 AM, Eric Dumazet wrote: >>> On 5/22/20 8:01 AM, Jon Maloy wrote: >>>> On 5/22/20 2:18 AM, Xin Long wrote: >>>>> On Fri, May 22, 2020 at 1:55 PM Eric Dumazet <edu...@go...> wrote: >>>>>> Resend to the list in non HTML form >>>>>> >>>>>> >>>>>> On Thu, May 21, 2020 at 10:53 PM Eric Dumazet <edu...@go...> wrote: >>>>>>> On Thu, May 21, 2020 at 10:50 PM Xin Long <luc...@gm...> wrote: >>>>>>>> On Fri, May 22, 2020 at 2:30 AM Eric Dumazet <edu...@go...> wrote: >>>>>>>>> dst_cache_get() documents it must be used with BH disabled. >>>>>>>> Interesting, I thought under rcu_read_lock() is enough, which calls >>>>>>>> preempt_disable(). >>>>>>> rcu_read_lock() does not disable BH, never. >>>>>>> >>>>>>> And rcu_read_lock() does not necessarily disable preemption. >>>>> Then I need to think again if it's really worth using dst_cache here. >>>>> >>>>> Also add tipc-discussion and Jon to CC list. >>>> The suggested solution will affect all bearers, not only UDP, so it is not a good. >>>> Is there anything preventing us from disabling preemtion inside the scope of the rcu lock? >>>> >>>> ///jon >>>> >>> BH is disabled any way few nano seconds later, disabling it a bit earlier wont make any difference. >> The point is that if we only disable inside tipc_udp_xmit() (the function pointer call) the change will only affect the UDP bearer, where dst_cache is used. >> The corresponding calls for the Ethernet and Infiniband bearers don't use dst_cache, and don't need this disabling. So it does makes a difference. >> > I honestly do not understand your concern, this makes no sense to me. > > I have disabled BH _right_ before the dst_cache_get(cache) call, so has no effect if the dst_cache is not used, this should be obvious. Forget my comment. I thought we were discussing to Tetsuo Handa's original patch, and missed that you had posted your own. I have no problems with this one. ///jon > > If some other paths do not use dst)cache, how can my patch have any effect on them ? > > What alternative are you suggesting ? > |