On Thu, Feb 28, 2019 at 10:35 AM Vlad Buslov <vla...@mellanox.com> wrote: > > > On Thu 28 Feb 2019 at 00:49, Cong Wang <xiyou.wangc...@gmail.com> wrote: > > On Tue, Feb 26, 2019 at 6:57 AM Vlad Buslov <vla...@mellanox.com> wrote: > >> > >> > >> On Mon 25 Feb 2019 at 22:39, Cong Wang <xiyou.wangc...@gmail.com> wrote: > >> > On Mon, Feb 25, 2019 at 8:11 AM Vlad Buslov <vla...@mellanox.com> wrote: > >> >> > >> >> > >> >> On Fri 22 Feb 2019 at 19:32, Cong Wang <xiyou.wangc...@gmail.com> wrote: > >> >> > > >> >> > So if it is no longer RCU any more, why do you still use > >> >> > rcu_dereference_protected()? That is, why not just deref it as a raw > >> >> > pointer? > >> > > >> > > >> > Any answer for this question? > >> > >> I decided that since there is neither possibility of concurrent pointer > >> assignment nor deallocation of object that it points to, most performant > >> solution would be using rcu_dereference_protected() which is the only > >> RCU dereference helper that doesn't use READ_ONCE. I now understand that > >> this is confusing (and most likely doesn't provide any noticeable > >> performance improvement anyway!) and will change this patch to use > >> rcu_dereference_raw() as you suggest. > > > > Yeah, please make sure sparse is happy with that. :) > > I checked my flower change with sparse. It produced a lot of warnings, > some of which are several years old. None in the code I changed though:
If so, we can address this later, it is not urgent.
