linux-kernel - Re: sparc64 cmpxchg is not a full memory barrier anymore ?

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: <20091022.145645.249762938.davem@davemloft.net>
Date:	Thu, 22 Oct 2009 14:56:45 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	mathieu.desnoyers@...ymtl.ca
Cc:	nickpiggin@...oo.com.au, linux-kernel@...r.kernel.org,
	paulmck@...ux.vnet.ibm.com
Subject: Re: sparc64 cmpxchg is not a full memory barrier anymore ?

From: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Date: Thu, 22 Oct 2009 14:32:42 -0400

> The same applies to the other atomic instructions we find in this list.
> How is the correct ordering of loads wrt to cmxchg (and other atomic
> ops) still ensured by this modification?

All actual sparc64 chips implement more strict ordering than
the V9 specification permits.  The memory barriers were just
nops and actually not doing anything more than the chip
already does for us.
--
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/