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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ