[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141116163355.GK4042@n2100.arm.linux.org.uk>
Date: Sun, 16 Nov 2014 16:33:56 +0000
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com, 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: ARM atomics overhaul for musl
On Sun, Nov 16, 2014 at 12:56:56AM -0500, Rich Felker wrote:
> Aside from that, the only case among the above that's "right" already
> is v7+. Hard-coding the mcr-based barrier on v6 is wrong because it's
I don't think it's wrong at all. The instruction isn't going away from
ARMv7, because ARMv7 deprecates it, but it _still_ has to be implemented
by a CPU conforming to ARMv7. As ARMv7 is going to be the last 32-bit
ARM architecture, we aren't going to see the MCR instruction disappearing
on 32-bit CPUs.
On ARMv8, it may have been removed, but we have already decided that the
kernel _must_ provide emulation for this op-code, because otherwise we
are breaking existing userspace, which is just not permissible. However,
you are absolutely right that running on ARMv8 should use the new
instruction where possible.
> However neither is really very easy because it seems impossible to
> detect whether the mcr-based barrier or the dmb-based barrier should
> be used -- there's no hwcap flag to indicate support for the latter.
> This also complicates what to do in builds for v6.
It is entirely possible to detect whether you should use mcr or dmb, and
you've said how to do that all the way through this message. The mcr
instruction is present on ARMv6, and present but deprecated on ARMv7.
dmb is only present on ARMv7. So, if you know the CPU architecture, you
know whether you should be using nothing, mcr, or dmb.
There's two ways to get that - firstly, the uname syscall, which gives
a string in the form "armv..." which gives the CPU architecture. The
second way is the ELF AT_PLATFORM entry. AT_PLATFORM has well defined
format, and is already used to select between different library versions
(so is already a user API, and is subject to user API rules). See:
$ grep string.*elf_name arch/arm/mm/proc*.S
for a list of the prefixes - the last character is always the endian-ness.
>From that, you can see that the format is "v" (for version), then the CPU
architecture number, followed (optionally) by any suffixes. Parse that
wisely, and you have the CPU architecture version, and the CPU architecture
version defines whether the MCR or DMB variant should be used.
See http://lwn.net/Articles/519085/ for a way to get at the ELF aux info
with recent glibc. I'm sure other C libraries will be getting their own
implementation of that for compatibility with glibc.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
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.
