linux-kernel - Re: [PATCH v3 3/5] MCS Lock: Barrier corrections

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

Message-ID: <CANN689EgdDQV=srsLELUpiTGOSF0SLUZ=BC2LnMxNrYTv3H=Wg@mail.gmail.com>
Date:	Thu, 7 Nov 2013 04:50:23 -0800
From:	Michel Lespinasse <walken@...gle.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Waiman Long <waiman.long@...com>, Arnd Bergmann <arnd@...db.de>,
	Rik van Riel <riel@...hat.com>,
	Aswin Chandramouleeswaran <aswin@...com>,
	"Paul E.McKenney" <paulmck@...ux.vnet.ibm.com>,
	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>,
	"Figo. zhang" <figo1802@...il.com>, linux-arch@...r.kernel.org,
	Andi Kleen <andi@...stfloor.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	George Spelvin <linux@...izon.com>,
	Tim Chen <tim.c.chen@...ux.intel.com>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Hurley <peter@...leysoftware.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-mm <linux-mm@...ck.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Alex Shi <alex.shi@...aro.org>, linux-kernel@...r.kernel.org,
	Scott J Norton <scott.norton@...com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Dave Hansen <dave.hansen@...el.com>,
	Matthew R Wilcox <matthew.r.wilcox@...el.com>,
	Will Deacon <will.deacon@....com>,
	Davidlohr Bueso <davidlohr.bueso@...com>
Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections

On Thu, Nov 7, 2013 at 4:06 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Nov 7, 2013 6:55 PM, "Michel Lespinasse" <walken@...gle.com> wrote:
>>
>> Rather than writing arch-specific locking code, would you agree to
>> introduce acquire and release memory operations ?
>
> Yes, that's probably the right thing to do. What ops do we need? Store with
> release, cmpxchg and load with acquire? Anything else?

Depends on what lock types we want to implement on top; for MCS we would need:
- xchg acquire (common case) and load acquire (for spinning on our
locker's wait word)
- cmpxchg release (when there is no next locker) and store release
(when writing to the next locker's wait word)

One downside of the proposal is that using a load acquire for spinning
puts the memory barrier within the spin loop. So this model is very
intuitive and does not add unnecessary barriers on x86, but it my
place the barriers in a suboptimal place for architectures that need
them.

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
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/