linux-kernel - Re: [PATCH 3/8] sparc32: unify __cmpxchg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b8df1921-1368-4355-a378-0c6cd02cdfc9@paulmck-laptop>
Date: Tue, 2 Apr 2024 13:02:26 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Alexander Viro <viro@...iv.linux.org.uk>, linux-kernel@...r.kernel.org,
	kernel-team@...a.com, "David S . Miller" <davem@...emloft.net>,
	Andreas Larsson <andreas@...sler.com>,
	Palmer Dabbelt <palmer@...osinc.com>,
	Marco Elver <elver@...gle.com>
Subject: Re: [PATCH 3/8] sparc32: unify __cmpxchg_u{32,64}

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@...iv.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