linux-kernel - Re: [RFC PATCH 1/1] remove redundant compare, cmpxchg already does it

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] [day] [month] [year] [list]

Date:	Fri, 6 Jun 2014 09:01:11 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Davidlohr Bueso <davidlohr@...com>
Cc:	Andev <debiandev@...il.com>, Pranith Kumar <pranith@...ech.edu>,
	LKML <linux-kernel@...r.kernel.org>, jason.low2@...com
Subject: Re: [RFC PATCH 1/1] remove redundant compare, cmpxchg already does it

On Thu, Jun 05, 2014 at 11:08:23AM -0700, Davidlohr Bueso wrote:
> I knew I had formally read this technique somewhere:
> http://pdos.csail.mit.edu/6.828/2010/readings/mcs.pdf (part 2.1).
> 
> Peter, what do you think of adding a new cmp_cmpxchg() or dcmpxchg()
> call for such scenarios?

Don't like dcmpxchg(), too easy to confuse with double-cmpxchg or
somesuch.

That said, I'm not entirely sure we want this primitive, the thing is,
people might use it ;-)

And its somewhat dangerous in that it explicitly does not provide any
kind of memory barrier on the fail path, where cmpxchg() is an
unconditional full memory barrier.

Also, you really don't want to use it in loops.

So I think it makes more sense to leave things as are and simply apply
the pattern where safe and meaningful.

Content of type "application/pgp-signature" skipped