Received-SPF: pass (google.com: domain of linux-kernel+bounces-94384-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Wed, 6 Mar 2024 13:20:12 -0500
From: Steven Rostedt <rostedt@goodmis.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: linke li <lilinke99@qq.com>, joel@joelfernandes.org,
 boqun.feng@gmail.com, dave@stgolabs.net, frederic@kernel.org,
 jiangshanlai@gmail.com, josh@joshtriplett.org,
 linux-kernel@vger.kernel.org, mathieu.desnoyers@efficios.com,
 qiang.zhang1211@gmail.com, quic_neeraju@quicinc.com, rcu@vger.kernel.org,
 Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] rcutorture: Fix
 rcu_torture_pipe_update_one()/rcu_torture_writer() data race and
 concurrency bug
Message-ID: <20240306132012.54a9ec01@gandalf.local.home>
In-Reply-To: <140c2d21-1d52-4c46-bbdd-f7b4b7eabbff@paulmck-laptop>
References: <f3624f39-bbb1-451d-8161-8518e4108d8e@joelfernandes.org>
	<tencent_9882B228F292088CDD68F10CF1C228742009@qq.com>
	<20240306103719.1d241b93@gandalf.local.home>
	<27665890-8314-4252-8622-1e019fee27e4@paulmck-laptop>
	<20240306130103.6da71ddf@gandalf.local.home>
	<140c2d21-1d52-4c46-bbdd-f7b4b7eabbff@paulmck-laptop>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 6 Mar 2024 10:09:48 -0800
"Paul E. McKenney" <paulmck@kernel.org> wrote:

> > Perhaps we need a way to annotate them, like we have with __rcu. "__shared"?
> > 
> > Then all accesses to that variable must be wrapped with a READ_ONCE() or
> > WRITE_ONCE()? I mean, if this can cause legitimate bugs, we should probably
> > address it like we do with locking and RCU.  
> 
> If we want that, just mark the field "volatile", as in "jiffies".

I already know Linus's view on "volatile" variables ;-)

> 
> And one of the strengths of READ_ONCE() and WRITE_ONCE() is that they
> allow non-volatile access where it is safe.  For example, if you hold the
> lock protecting all stores to that variable, you still need WRITE_ONCE()
> but not READ_ONCE().  In initialization and cleanup code, you don't
> need either.

I guess the current static analyzers just look to see where READ_ONCE() or
WRITE_ONCE() is used and checks to see if other places have them properly
used. I'm guessing that's where the OP patch came from.

Sounds like we just need a ADD_ONCE() or INC_ONCE() then. Because I am not
taking a

	WRITE_ONCE(a, READ_ONCE(a) + 1);

patch that replaces a simple "a++".

-- Steve