[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20241107140117.3790954-1-zilinguan811@gmail.com>
Date: Thu, 7 Nov 2024 14:01:17 +0000
From: Zilin Guan <zilinguan811@...il.com>
To: paulmck@...nel.org
Cc: boqun.feng@...il.com,
frederic@...nel.org,
jiangshanlai@...il.com,
joel@...lfernandes.org,
josh@...htriplett.org,
linux-kernel@...r.kernel.org,
mathieu.desnoyers@...icios.com,
neeraj.upadhyay@...nel.org,
qiang.zhang1211@...il.com,
rcu@...r.kernel.org,
rostedt@...dmis.org,
urezki@...il.com,
zilinguan811@...il.com,
xujianhao01@...il.com
Subject: Re: [PATCH] rcu: Use READ_ONCE() for rdp->gpwrap access in __note_gp_changes()
On Wed, Nov 06, 2024 at 12:18:25PM -0800, Paul E. McKenney wrote:
> Good eyes!!!
>
> But did you find this with KCSAN, or by visual inspection?
>
> The reason that I ask is that the __note_gp_changes() should be
> invoked with the leaf rnp->lock held, which should exclude writes to
> the rdp->gpwrap fields for all CPUs corresponding to that leaf rcu_node
> structure.
>
> Note the raw_lockdep_assert_held_rcu_node(rnp) call at the beginning of
> this function.
>
> So I believe that the proper fix is to *remove* READ_ONCE() from accesses
> to rdp->gpwrap in this function.
>
> Or am I missing something here?
>
> Thanx, Paul
I found this by visual inspection.
When reviewing the function __note_gp_changes(), I noticed that other
accesses to rdp->gpwrap are protected with either READ_ONCE() or
WRITE_ONCE(), which led me to suspect a potential data race at line 1305.
However, I am not certain whether holding rnp->lock protects access to
rdp->gpwrap in this case. If it indeed ensures that no concurrent writes
can occur, then I agree that the correct approach would be to remove
READ_ONCE() from those accesses.
Thanks,
Zilin
Powered by blists - more mailing lists