Date: Thu, 16 Mar 2017 17:27:03 +0000 From: Andrew Gierth <andrew@tao11.riddles.org.uk> To: Sylvain Garrigues <sylvain@sylvaingarrigues.com> Cc: mmel@freebsd.org, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Is CPUTYPE=cortex-A7 supposed to work? Message-ID: <87pohh2n3c.fsf@news-spur.riddles.org.uk> In-Reply-To: <ED8405B6-1150-4A9C-AD93-5C74306FB361@sylvaingarrigues.com> (Sylvain Garrigues's message of "Thu, 16 Mar 2017 17:14:06 %2B0100") References: <871suc3nv8.fsf@news-spur.riddles.org.uk> <CANCZdfq4EwH%2B_9FVNai8s6Y-gdTjHJ8dNkJwSrnF%2BSAkdwvYdg@mail.gmail.com> <8737ely05c.fsf@news-spur.riddles.org.uk> <CANCZdfpftVHaPahTOP0vxB-FR%2BKtpqY9JMJr=F2DGifD0fhKMQ@mail.gmail.com> <87wpbxw3yd.fsf@news-spur.riddles.org.uk> <79EBD44B-2C2D-4394-A90C-DF494A049F20@dsl-only.net> <E6BC9F77-F65B-4918-9E22-3BFECA268E30@sylvaingarrigues.com> <674facba-68cd-8ce1-887a-1ef3c51520bc@freebsd.org> <ED8405B6-1150-4A9C-AD93-5C74306FB361@sylvaingarrigues.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "Sylvain" =3D=3D Sylvain Garrigues <sylvain@sylvaingarrigues.com> wri= tes: Sylvain> Thank you so much for your quick feedback Michal. Good to know Sylvain> this matter is into good hands. I=E2=80=99m afraid I'm still afra= id Sylvain> about `basic=E2=80=99 programs like git being still potentially b= roken Sylvain> when kernel+world+ports have CPUTYPE=3Dcortex-a7 in make.conf - Sylvain> Andrew said a simple `git clone' could fail, more precisely Sylvain> (quoting him): =20 >> I have determined that the sha1 failures occur only if the >> NEON-enabled SHA1 block function is interrupted by a signal. This >> explains why it fails in git (which is using SIGALRM to set a >> "display progress" flag) but not in standalone SHA1 tests; Sylvain> Removing CPUTYPE apparently fixes things hence I=E2=80=99m not 10= 0% Sylvain> confident yet of keeping CPUTYPE=3Dcortex-a7 myself even if only Sylvain> a few ports might be affected. Git is an important port, who Sylvain> knows what other ports are broken :-) Let me clarify this. Without CPUTYPE, things _appear_ to work because only explicit use of floating-point exposes the bug, and it's extremely rare for programs to use floating-point in signal handlers, and even then the only result would be incorrect floating-point calculations in the interrupted code. With CPUTYPE, the compiler can generate NEON instructions for integer code; even without heavy optimization enabled, it might choose to use NEON register load/store to copy small data structures for example. One piece of code which is affected by this is the signal handling functions in libthr, which wrap the program's own signal handler functions; so now, _every_ signal handler in a program linked with libthr uses the NEON registers, and the result isn't limited to corrupting floating-point calculations but can corrupt data structures or copied memory, or the results of vectorized code. The specific failures that I saw -- git failing, emacs crashing, errors from openssl speed -- were all of this second kind and therefore not directly reproducible without CPUTYPE; but the test program I gave for the bug report demonstrates the problem by using explicit floating-point (in a highly contrived way) and therefore reproduces the issue even without CPUTYPE. So even though the bug is in the kernel and affects all armv6 targets whether NEON is in use or not, the chances of actually hitting it are pretty negligible if you built the world without CPUTYPE. But if you build with CPUTYPE, then potentially any code that catches a signal is affected; it's just that programs (like git) that combine signal handling with vectorized crypto code, or programs (like emacs) that use signal handling very heavily, have the greatest probability of failure. tl/dr: building without CPUTYPE is a workaround that simply reduces both the chance and severity of failure; building with CPUTYPE currently breaks almost everything, but with a probability that varies wildly depending on what the application does. --=20 Andrew.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87pohh2n3c.fsf>