linux-kernel - Re: [PATCH 8/8] i386: bitops: smp_mb__{before, after}_clear

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: <46A5EA1E.7000008@yahoo.com.au>
Date:	Tue, 24 Jul 2007 22:01:34 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Satyam Sharma <ssatyam@....iitk.ac.in>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	David Howells <dhowells@...hat.com>, Andi Kleen <ak@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 8/8] i386: bitops: smp_mb__{before, after}_clear_bit()
 definitions

Satyam Sharma wrote:
> On Tue, 24 Jul 2007, Nick Piggin wrote:

>>>>Are you saying that it is OK for the store to var to
>>>>be reordered below the clear_bit? If not, what are you
>>>>saying?
>>>
>>>
>>>I might be making a radical turn-around here, but all of a
>>>sudden I think it's actually a good idea to put a complete
>>>memory clobber in set_bit/clear_bit and friends themselves,
>>>and leave the "__" variants as they are.
>>
>>Why?
> 
> 
> Well, why not. Callers who don't want/need any guarantees whatsoever
> can still use __foo() -- for others, it makes sense to just use
> foo() and get *both* the compiler and CPU barrier semantics -- I think
> that's the behaviour most callers would want anyway.

Firstly, __foo() is non-atomic, secondly set_bit/clear_bit/etc do not
provide any CPU or compiler semantics.

It was set up this way because other CPU ISAs don't couple atomicity
with memory ordering, and with many implementations of those, the cost
to order memory is quite high.

-- 
SUSE Labs, Novell Inc.
-
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/