Announcement

Collapse
No announcement yet.

Linux 5.2+ Hit By AVX Register Corruption Bug - Affecting At Least Golang Programs

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux 5.2+ Hit By AVX Register Corruption Bug - Affecting At Least Golang Programs

    Phoronix: Linux 5.2+ Hit By AVX Register Corruption Bug - Affecting At Least Golang Programs

    The Linux 5.2 kernel and newer appears to be suffering from an AVX register corruption bug stemming from signal delivery. This register corruption issue is manifesting itself at least for Golang programs leading to a variety of bug reports when running on Linux 5.2 through at least the newly-minted Linux 5.4...

    http://www.phoronix.com/scan.php?pag...gister-Corrupt

  • #2
    gcc again miscompiled some code?

    Comment


    • #3
      Maybe I misunderstood something but it looks like a hw issue/CPU bug.

      Comment


      • #4
        Originally posted by birdie View Post
        Maybe I misunderstood something but it looks like a hw issue/CPU bug.
        According to https://bugzilla.kernel.org/show_bug.cgi?id=205663#c1 this looks like a compiler bug to me.

        Comment


        • #5
          Kudos to the golang-devs for tracking this down.

          Comment


          • #6
            Originally posted by zxy_thf View Post
            According to https://bugzilla.kernel.org/show_bug.cgi?id=205663#c1 this looks like a compiler bug to me.
            So, does the problem occur if the kernel is compiled with clang/llvm? (ducks for cover to avoid the incoming...)

            Comment


            • #7
              Oh yikes! I just read the bug report and it's pretty ugly. Please let us know when a patch is released Michael, I'm running 5.4 compiled with GCC9 even as we speak.

              Comment


              • #8
                Originally posted by zxy_thf View Post
                According to https://bugzilla.kernel.org/show_bug.cgi?id=205663#c1 this looks like a compiler bug to me.
                Not necessarily. The existing code may have been relying on undefined behaviour. The compiler may have the full right to optimize this and just by the fact that GCC 8 did not do it, doesn't mean that GCC 9 is buggy.

                Compilers are under constant pressure of improving their optimizations and the consequence is that they more strictly follow the C/C++ standard as to what they are allowed to optimize and what not. Buggy code that assumes the compiler will compile it in a certain way, while the standard doesn't give that guarantee often becomes a victim of newer compilers.

                Comment


                • #9
                  Originally posted by CommunityMember View Post
                  So, does the problem occur if the kernel is compiled with clang/llvm? (ducks for cover to avoid the incoming...)
                  Probably not. However there is nothing unusual in these sorts of bugs getting through. An error like this highlights why having alternatives is so important.

                  Comment


                  • #10
                    Originally posted by zxy_thf View Post
                    According to https://bugzilla.kernel.org/show_bug.cgi?id=205663#c1 this looks like a compiler bug to me.
                    Not sure if it's a compiler bug, from a look at the code it could also be a missing compiler optimization barrier in the kernel. Cohabitation of optimizing compilers that cache the contents of memory in registers, with low-level constructs like context switches that randomly change the contents of memory without warning the compiler about it, is fundamentally hard...

                    Comment

                    Working...
                    X