linux-kernel - Re: [PATCH] doc: atomic_add_unless() doesn't imply mb() on failure

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] [day] [month] [year] [list]

Message-ID: <11754.1164884513@redhat.com>
Date:	Thu, 30 Nov 2006 11:01:53 +0000
From:	David Howells <dhowells@...hat.com>
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	Andrew Morton <akpm@...l.org>, David Howells <dhowells@...hat.com>,
	Alan Stern <stern@...land.harvard.edu>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] doc: atomic_add_unless() doesn't imply mb() on failure 

Oleg Nesterov <oleg@...sign.ru> wrote:

> Most implementations of atomic_add_unless() can fail (return 0) after the
> first atomic_read() (before cmpxchg). In that case we have a compiler
> barrier only.

Ummm...  I wonder if we should instead change the behaviour of
atomic_add_unless() to include an explicit smp_rmb() between the read and the
conditional jump on all archs where this isn't already implied.  Otherwise,
what governs when the initial test going to be done by the CPU?

Note that not all archs do cmpxchg() here, though I don't think that affects
your argument.

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