Received-SPF: pass (google.com: domain of linux-kernel+bounces-128628-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Tue, 2 Apr 2024 13:02:26 -0700
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>, linux-kernel@vger.kernel.org,
	kernel-team@meta.com, "David S . Miller" <davem@davemloft.net>,
	Andreas Larsson <andreas@gaisler.com>,
	Palmer Dabbelt <palmer@rivosinc.com>,
	Marco Elver <elver@google.com>
Subject: Re: [PATCH 3/8] sparc32: unify __cmpxchg_u{32,64}
Message-ID: <b8df1921-1368-4355-a378-0c6cd02cdfc9@paulmck-laptop>
Reply-To: paulmck@kernel.org
References: <20240402041138.GF538574@ZenIV>
 <20240402042835.11815-1-viro@zeniv.linux.org.uk>
 <20240402042835.11815-3-viro@zeniv.linux.org.uk>
 <d85654ba-54b5-419a-89e5-526660284769@app.fastmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <d85654ba-54b5-419a-89e5-526660284769@app.fastmail.com>

On Tue, Apr 02, 2024 at 09:28:57AM +0200, Arnd Bergmann wrote:
> On Tue, Apr 2, 2024, at 06:28, Al Viro wrote:
> > Add a macro that expands to one of those when given u32 or u64
> > as an argument - atomic32.c has a lot of similar stuff already.
> >
> > Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> 
> I think we should merge Sam's series to remove non-CAS sparc32
> first:
> 
> https://lore.kernel.org/all/20240309-sunset-v2-0-f09912574d2c@ravnborg.org/
> 
> I don't see a patch yet to actually change cmpxchg() to use CAS,
> but it can probably just share the sparc64 implementation at
> that point.

Fair points!

In the meantime, I pulled in Al's patches for both sparc and parisc.

If I leave out sparc support, I am inducing build failures on sparc in
RCU code.  I do not feel comfortable pulling in Sam's series.

One approach is for me to push in the emulation and uses as they are
accepted, and modify from there.

Another approach would be for me to add KCSAN annotation to RCU's current
open-coded one-byte emulation and let things play out from there.

A third would be for us all to deadlock on each other.

My preference is the first approach.  But what would work better?

							Thanx, Paul