linux-kernel - Re: [PATCH -v5][RFC]: mutex: implement adaptive spinning

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:	Wed, 7 Jan 2009 14:06:40 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Steven Rostedt <rostedt@...dmis.org>, paulmck@...ux.vnet.ibm.com,
	Gregory Haskins <ghaskins@...ell.com>,
	Ingo Molnar <mingo@...e.hu>, Matthew Wilcox <matthew@....cx>,
	Andi Kleen <andi@...stfloor.org>,
	Chris Mason <chris.mason@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-btrfs <linux-btrfs@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Nick Piggin <npiggin@...e.de>,
	Peter Morreale <pmorreale@...ell.com>,
	Sven Dietrich <SDietrich@...ell.com>
Subject: Re: [PATCH -v5][RFC]: mutex: implement adaptive spinning

On Wed, 7 Jan 2009, Linus Torvalds wrote:
> 
> We don't actually care that it only happens once: this all has _known_ 
> races, and the "cpu_relax()" is a barrier.

I phrased that badly. It's not that it has "known races", it's really that 
the whole code sequence is very much written and intended to be 
optimistic.

So whatever code motion or whatever CPU memory ordering motion that 
happens, we don't really care, because none of the tests are final. We do 
need to make sure that the compiler doesn't optimize the loads out of the 
loops _entirely_, but the "cpu_relax()" things that we need for other 
reasons guarantee that part.

One related issue: since we avoid the spinlock, we now suddenly end up 
relying on the "atomic_cmpxchg()" having lock acquire memory ordering 
semantics. Because _that_ is the one non-speculative thing we do end up 
doing in the whole loop. 

But atomic_cmpxchg() is currently defined to be a full memory barrier, so 
we should be ok. The only issue might be that it's _too_ much of a memory 
barrier for some architectures, but this is not the pure fastpath, so I 
think we're all good.

			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/