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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ