linux-kernel - Re: [PATCH v2] introduce atomic_pointer to fix a race condition in cancelable mcs spinlocks

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CA+55aFwJwVf_MbcwNNWg-KrLdoOaV2xse2jzvBZTJHJgC_Htvg@mail.gmail.com>
Date:	Mon, 2 Jun 2014 13:22:10 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Waiman Long <waiman.long@...com>,
	Mikulas Patocka <mpatocka@...hat.com>,
	"James E.J. Bottomley" <jejb@...isc-linux.org>,
	Helge Deller <deller@....de>,
	John David Anglin <dave.anglin@...l.net>,
	Parisc List <linux-parisc@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	"Vinod, Chegu" <chegu_vinod@...com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Rik van Riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Davidlohr Bueso <davidlohr@...com>,
	Peter Anvin <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
	"Chandramouleeswaran, Aswin" <aswin@...com>,
	"Norton, Scott J" <scott.norton@...com>,
	Jason Low <jason.low2@...com>
Subject: Re: [PATCH v2] introduce atomic_pointer to fix a race condition in
 cancelable mcs spinlocks

On Mon, Jun 2, 2014 at 1:05 PM, Peter Zijlstra <peterz@...radead.org> wrote:
>
> So the question is, do you prefer subtly broken code or hard compile
> fails? Me, I go for the compile fail.

The thing is, parisc has a perfectly fine "cmpxchg" implementation in
practice, and ACCESS_ONCE() and friends work fine too for reading.

What the "use a spinlock" approach cannot generally do is:

 - ACCESS_ONCE() to _write_ things doesn't work well. You really
should use "atomic_set()".

 - you may not necessarily be able to mix partial updates (ie
differently sized updates to the same thing) depending on just how the
spinlock hashing works

but both of those are really rare issues and don't affect normal code.

I would not necessarily be opposed to splitting up ACCESS_ONCE() for
reading and for writing, and maybe we could do something special for
the writing path (which tends to be less ctitical). It's really mixing
"ACCESS_ONCE(x)" to _set_ a value, together with atomic ops to update
it, that ends up being problematic.

Maybe there are other issues I can't think of right now. But
basically, parisc _can_ do cmpxchg, it's just that the code needs to
be somewhat sanitized.

Side note: some of the RCU code uses "ACCESS_ONCE()" for
read-modify-write code, which is just f*cking crazy. The semantics are
dubious, and it generally makes gcc create bad code too.

                 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/