Red Hat Linux Critical bugs will affect servers based on the Haswell architecture

Recently, the CTO and co-founder Gil Tene of Azul Systems reported a very important but little-known Linux kernel patch, especially for Linux system users and administrators using the Intel Haswell architecture. In particular, users based on the Red Hat release (including CentOS 6.6 and ScientificLinux6.6) should update this patch immediately. Even with Linux running in a virtual machine, if the virtual machine is on a popular cloud platform (such as Azure, Amazon, etc.), it may also run on the Haswell machine, and patching should be beneficial. Tene is a description of the flaw: the impact of this kernel vulnerability is simple: in some seemingly impossible situations, the user process is deadlocked and suspended. Any Futex call waiting (even if it is woken correctly) is likely to be blocked from execution forever. Just like Thread.park () in Java can always block that, and so on. If you're lucky enough, you'll find soft lockup messages in the DMESG log, and if you're not so lucky (like with us), you'll have to spend a few months on labor costs to troubleshoot problems in your code and possibly get nowhere. "Tene continues to explain how this flaw code is executed (which can eventually be attributed to a switch block that misses the default case). The biggest problem now is that, although the problem code was fixed in January 2014, the flaw was moved back to the Red Hat 6.6 family system around October 2014. Other systems, including SLEs, Ubuntu, and Debian, may also be affected. The remediation of these systems is now inconsistent and may be overlooked. Redhat users should use Rhel 6.6.z or newer versions. Tene also points out that another key point is that different distributions have different options for what to put into the kernel, which also leads to inconsistent fixes. For example, for Rhel 7.1, "there is actually no such bug in the upstream 3.10 kernel, but the RHEL7 kernel is not a purely upstream version." Unfortunately, Rhel 7.1 (like RHEL6.6) included this bug in the porting (based on RHEL version 7). I think other distributions may have done the same. "For Rhel-based distributions, Tene provides a quick reference list: L RHEL 5 (including CentOS5 and scientific Linux 5): all editions (including version 5.11) have no problem. L RHEL 6 (including CentOS6 and scientific Linux 6): from 6.0~6.5Version is fine. However, version 6.6 is defective, and 6.6.z is not a problem. L RHEL 7 (including CentOS7 and scientific Linux 7): 7.1 is defective. And as of May 13, 2015 there is not a 7.x fix. Although there is some controversy over the number of affected systems on Hacker news, it provides some context to check if your system needs to be repaired. Free pick up the lamp brother even original Linux OPS engineer video/Detailed Linux tutorials, details Inquiries official website customer service: http://www.lampbrother.net/linux/

