Date: Mon, 17 Nov 2014 16:53:34 +0000 From: Russell King - ARM Linux <linux@....linux.org.uk> To: Catalin Marinas <catalin.marinas@....com> Cc: Rich Felker <dalias@...c.org>, Szabolcs Nagy <nsz@...t70.net>, "musl@...ts.openwall.com" <musl@...ts.openwall.com>, Kees Cook <keescook@...omium.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, Andy Lutomirski <luto@...capital.net> Subject: Re: ARM atomics overhaul for musl On Mon, Nov 17, 2014 at 04:19:42PM +0000, Catalin Marinas wrote: > This indeed works and it is likely the way you designed it with the > _arm32_ kernel in mind (but not before accusing the arm64 maintainers of > making a bad decision with the "aarch64" AT_PLATFORM string for compat > apps ;)). Seeing as I'm the ARM32 maintainer, and you are the ARM64 maintainer, then of course I designed it with the ARM32 kernel in mind, with a reference into the ARM64 situation to the best of my knowledge, which suggested that compat tasks got the "aarch64" string. As you have pointed out, they don't, they get a "v8l" string, which means... > In your code sequence, the "aarch64" check should be removed, unless you > aim it at portable code between 32 and 64-bit but I would rather use an > #ifdef __aarch64__ in such case. On AArch64 (nothing to do with ARMv8, > v9 etc.), we should move away from thinking in terms of architecture > version numbers but just features. ... that it can indeed be removed. To repeat, the check for "aarch64" was only there because I thought that ARM64 kernels used that for everything. > Similarly for AArch32, I think we should switch our focus from version > numbers (well, only from v7/v8) to features (exposed by the hardware to > the kernel via CPUID). An example is how we got LPAE on ARMv7 without a > change in the architecture version number. We even expose this to user > space via hwcap because that's how we know we have atomic LDRD/STRD. For this case, I disagree. There is no value (in fact, there is lots of harm) to adding a hwcap bit for this. If we added such a hwcap bit, it would mean that userspace would have to implement the check that I suggested, plus a check for the hwcap bit, plus maybe a kernel version check to decide which test to use. That is needlessly complicated. Okay, you could decide that if the hwcap bit is set, then that indicates that DMB should be used, but you still have to then check the architecture version if it isn't set to be compatible with old kernels. So, it's all round simpler just to do the architecture version check - and we know for certain that ARMv4, ARMv5, and ARMv6 do not have dmb. We know that ARMv7 and ARMv8 both have dmb, and it is likely (especially if you exert pressure on the architecture people) that dmb will remain implemented. We also know that ARMv6 implements the mcr instruction. So, in this case, we know everything we need to know just by looking at the architecture version. Of course, we can't predict the future with any accuracy, but hoping that dmb won't be deprecated and obsoleted is a reasonable hope, and if it does, we would need to modify the code to add the new method in any case. What the code is *intentionally* safe from is the architecture number incrementing. So, I really don't see the point in exposing the presence of DMB via a hwcap bit - if we wanted to do that, it's something that we should have done at the very start, but we didn't. Now, it's pointless to do so. -- 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.