linux-kernel - xchg() and cmpxchg()

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]

Message-ID: <4C4F7277.8050306@zytor.com>
Date:	Tue, 27 Jul 2010 16:57:43 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Avi Kivity <avi@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Peter Palfrader <peter@...frader.org>,
	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	stable@...nel.org, stable-review@...nel.org,
	akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
	Glauber Costa <glommer@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>,
	Marcelo Tosatti <mtosatti@...hat.com>
Subject: xchg() and cmpxchg()

Okay, I've stared at this issue for most of the day, and I have a fix
for the immediate issue.

However, I also am convinced that the whole scheme with the __xg() macro
is just broken.  It was introduced in 1.3.11 when xchg and cmpxchg where
neither "asm volatile" nor had "memory" clobbers as an apparent way to
keep gcc from moving memory references around it, but since the array
type is "unsigned long" rather than a char type, it probably doesn't
even work right, and with asm volatile/memory clobber it should not be
necessary.

At this point I'd like to push an urgent patch to fix the immediate
issue, and a cleanup patch getting rid of __xg() for .36.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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