linux-kernel - Re: [PATCH] x86: cmpxchg_double: Add missing memory clobber

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:	Tue, 6 Oct 2015 14:39:02 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Pranith Kumar <bobby.prani@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
	"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: cmpxchg_double: Add missing memory clobber

On 10/06/2015 01:29 PM, Pranith Kumar wrote:
> On Tue, Oct 6, 2015 at 4:16 PM, H. Peter Anvin <hpa@...or.com> wrote:
>>
>> NAK.  We already have the "+m" for exactly this reason; adding an
>> explicit memory clobber should only be used to prevent movement of
>> *other* memory operations around this one (i.e. a barrier).
>>
> 
> OK. If that is so, can you please explain why we need it in the
> __raw_cmpxchg() case? I think it is a good idea to make cmpxchg() and
> cmpxchg_double() have similar barrier semantics.
> 

OK, it is a bit of a mess.  We use the same macros for locked operations
(__cmpxchg and __sync_cmpxchg) and unlocked operations
(__cmpxchg_local).  For locked operations we generally want a compiler
barrier, although there are exceptions.  I'm wondering if it would be
better to add an explicit barrier(); to the locked versions.

However, I think one of the major uses for cmpxchg_double() is for page
table manipulation, and for that it isn't clear that a compiler barrier
is needed nor desired.

On the other hand, perhaps all of this is false optimization and we
should just add the memory clobber.  The real issue is the impact on the
_local variants.

	-hpa

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