Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 27 Jun 2014 20:11:43 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Cc: Andy Lutomirski <luto@...capital.net>, Szabolcs Nagy <nsz@...t70.net>,
	Kees Cook <keescook@...omium.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>
Subject: Re: Re: Thread pointer changes

On Fri, Jun 27, 2014 at 11:54:45PM +0100, Russell King - ARM Linux wrote:
> Oh, I should also have mentioned: for a libc, if you want to stretch
> across from ARMv4 all the way up to ARMv7, then you have to do lots
> more than just worry about thread local storage.  You also have the
> problem that you can't just fall back on the SWP instruction to
> provide atomic implementations - this instruction has been deprecated
> and for the latest CPUs, the kernel may be configured to emulate this
> instruction.  Besides, on ARMv6 and later, you really want to use the
> load/store exclusive instructions for implementing atomic accesses
> and not the horrid SWP instruction.  So you need to implement atomic
> stuff using SWP for some CPUs and the new load/store exclusive for
> other CPUs.

SWP is mostly useless for implementing the POSIX threads primitives,
most of which need compare-and-swap due to the requirement of
self-synchronized destruction. At the source level we do a swap
operation in a couple places, but so far on ARM it's just implemented
in terms of CAS. We could revisit this once there's runtime selection
of the lock code anyway; using SWP might make a big difference for
internal locks (e.g. in malloc) where the CAS semantics are not
needed.

Rich

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.