linux-kernel - Re: [PATCH] bitops: add

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, 9 May 2012 19:36:42 +0300
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Rob Landley <rob@...dley.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
	Arnd Bergmann <arnd@...db.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Howells <dhowells@...hat.com>,
	Akinobu Mita <akinobu.mita@...il.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Herbert Xu <herbert@...dor.hengli.com.au>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, Gleb Natapov <gleb@...hat.com>,
	Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org,
	Avi Kivity <avi@...hat.com>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] bitops: add _local bitops

On Wed, May 09, 2012 at 09:24:41AM -0700, H. Peter Anvin wrote:
> On 05/09/2012 08:47 AM, Michael S. Tsirkin wrote:
> > 
> > By the way, clear_bit on x86 does not seem to contain
> > an optimization barrier - is my reading correct?
> > Lock prefix does not affect the compiler, right?
> 
> Yes, as it clearly states in the comment:
> 
>  * clear_bit() is atomic and may not be reordered.  However, it does
>  * not contain a memory barrier, so if it is used for locking purposes,
>  * you should call smp_mb__before_clear_bit() and/or
> smp_mb__after_clear_bit()
>  * in order to ensure changes are visible on other processors.
> 
> There is clear_bit_unlock() which has the barrier semantics.
> 
> 	-hpa

Well it talks about a memory barrier, not an
optimization barrier.

If compiler reorders code, changes will appear in
the wrong order on the current processor,
not just on other processors, no?

Sorry if I'm confused about this point, this is
what Documentation/atomic_ops.txt made me believe:
<quote>
	For example consider the following code:

		while (a > 0)
			do_something();

	If the compiler can prove that do_something() does not store to the
	variable a, then the compiler is within its rights transforming this to
	the following:

		tmp = a;
		if (a > 0)
			for (;;)
				do_something();

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