Messages in this thread | | | Date | Wed, 19 Jul 2023 11:20:36 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH rcu 6/6] rcu: Use WRITE_ONCE() for assignments to ->next for rculist_nulls |
| |
On Tue, Jul 18, 2023 at 09:48:59PM -0400, Joel Fernandes wrote: > > > On 7/18/23 14:32, Paul E. McKenney wrote: > > On Tue, Jul 18, 2023 at 10:48:07PM +0800, Alan Huang wrote: > > > > > > > 2023年7月18日 21:49,Joel Fernandes <joel@joelfernandes.org> 写道: > > > > > > > > On 7/17/23 14:03, Paul E. McKenney wrote: > > > > > From: Alan Huang <mmpgouride@gmail.com> > > > > > When the objects managed by rculist_nulls are allocated with > > > > > SLAB_TYPESAFE_BY_RCU, old readers may still hold references to an object > > > > > even though it is just now being added, which means the modification of > > > > > ->next is visible to readers. This patch therefore uses WRITE_ONCE() > > > > > for assignments to ->next. > > > > > Signed-off-by: Alan Huang <mmpgouride@gmail.com> > > > > > Signed-off-by: Paul E. McKenney <paulmck@kernel.org> > > > > > > > > Did we ever conclude that the READ_ONCE() counterparts were not needed? ;-) > > > > > > Read-side is already protected by rcu_dereference_raw() in hlist_nulls_for_each_entry_{rcu, safe}. > > > > It turns out that different traversal synchronization designs want > > different pointers using WRITE_ONCE(). > > Thank you Alan and Paul, > > Btw, I don't see any users of hlist_nulls_unhashed_lockless(), maybe it can > be removed?
Either that or the people who removed uses injected bugs...
But if this one really does go away, do we need ->pprev to be protected by _ONCE()?
Thanx, Paul
| |