[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <449d0d48-ac98-659b-4d03-e75c318605d4@joelfernandes.org>
Date: Tue, 18 Jul 2023 21:48:59 -0400
From: Joel Fernandes <joel@...lfernandes.org>
To: paulmck@...nel.org, Alan Huang <mmpgouride@...il.com>
Cc: rcu@...r.kernel.org, linux-kernel@...r.kernel.org,
kernel-team@...a.com, rostedt@...dmis.org
Subject: Re: [PATCH rcu 6/6] rcu: Use WRITE_ONCE() for assignments to ->next
for rculist_nulls
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@...lfernandes.org> 写道:
>>>
>>> On 7/17/23 14:03, Paul E. McKenney wrote:
>>>> From: Alan Huang <mmpgouride@...il.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@...il.com>
>>>> Signed-off-by: Paul E. McKenney <paulmck@...nel.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?
- Joel
Powered by blists - more mailing lists