linux-kernel - Re: [PATCH] x86: Generate cmpxchg build failures

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: <alpine.LFD.2.01.0910051210280.3432@localhost.localdomain>
Date:	Mon, 5 Oct 2009 12:16:08 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	John Stultz <johnstul@...ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH] x86: Generate cmpxchg build failures

On Mon, 5 Oct 2009, Peter Zijlstra wrote:

> On Tue, 2009-09-29 at 14:17 -0700, Linus Torvalds wrote:
> 
> > And regardless, we should fix the silent cmpxchg failure, even if it's 
> > just a link-time failure or something.
> 
> Something like the below?

Looks good to me. This is also one of the cases where a macro will do 
better than an inline function, since the return value depends on the size 
of the pointer, and it doesn't do the whole 'unsigned long' thing any 
more.

It should also be fairly easy to make this now just do a cmpxchg8b for the 
64-bit case (again, that wouldn't have worked sanely due to the fixed type 
in the inline function version - expanding that size to 64-bit would have 
been insane). But that's a separate issue (and maybe we don't want to do 
it, due to the whole "it's not DMA-atomic" etc issue - we may be better 
off with a build failure, and forcing people who really want 64-bit 
accesses to use the explicit cmpxchg64 thing)

That said, I think that you should merge the insane three versions of this 
macro into one. Having separate versions for "__[sync_|local_|]cmpxchg()" 
is disgusting. I bet you can do it with a single macro, and just pass in 
the LOCK_PREFIX (or empty, or "lock;") to that as needed. Rather than 
duplicating it three times.

			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/