On Wed, Jul 3, 2019 at 4:33 PM Xin Long <lucien....@gmail.com> wrote: > > On Wed, Jul 3, 2019 at 6:08 AM David Miller <da...@davemloft.net> wrote: > > > > From: Xin Long <lucien....@gmail.com> > > Date: Tue, 2 Jul 2019 00:54:55 +0800 > > > > > For these places are protected by rcu_read_lock, we change from > > > rcu_dereference_rtnl to rcu_dereference, as there is no need to > > > check if rtnl lock is held. > > > > > > For these places are protected by rtnl_lock, we change from > > > rcu_dereference_rtnl to rtnl_dereference/rcu_dereference_protected, > > > as no extra memory barriers are needed under rtnl_lock() which also > > > protects tn->bearer_list[] and dev->tipc_ptr/b->media_ptr updating. > > > > > > rcu_dereference_rtnl will be only used in the places where it could > > > be under rcu_read_lock or rtnl_lock. > > > > > > Signed-off-by: Xin Long <lucien....@gmail.com> > > > > In the cases where RTNL is held, even if rcu_read_lock() is also taken, > > we should use rtnl_dereference() because that avoids the READ_ONCE(). > Right, that's what I did in this patch. > > But for the places where it's sometimes called under rtnl_lock() only and > sometimes called under rcu_read_lock() only, like tipc_udp_is_known_peer() > and tipc_udp_rcast_add(), I kept rcu_dereference_rtnl(). makes sense? Hi, David, I saw this patch in "Changes Requested".
I've checked all places with this patch, no function calling rcu_dereference() and rcu_dereference_rtnl() will be ONLY called under rtnl_lock() protection. So I can't see a problem with it. Do I need to resend?
