Announcement

Collapse
No announcement yet.

The Linux 5.2+ "Register Corruption" Bug / Golang Issue Was A One-Line Kernel Caching Issue

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

  • The Linux 5.2+ "Register Corruption" Bug / Golang Issue Was A One-Line Kernel Caching Issue

    Phoronix: The Linux 5.2+ "Register Corruption" Bug / Golang Issue Was A One-Line Kernel Caching Issue

    Coming together just over a day ago was the Google folks working on Golang figuring out many Go issues stemmed from a bug on the Linux 5.2 kernel and newer that was worked out to be some sort of a register corruption issue. That issue is now sorted out and fortunately it's a one-line kernel fix and boils down to being a caching issue...

    http://www.phoronix.com/scan.php?pag...rupt-Issue-Fix

  • #2
    Another bug fix. Anything special about it?

    Comment


    • #3
      Originally posted by timofonic View Post
      Another bug fix. Anything special about it?
      It kept a bunch of real world servers and developers on older versions of Go and the kernel during a period where Go was focusing on introducing new features and collecting real world feedback.

      Comment


      • #4
        Originally posted by timofonic View Post
        Another bug fix. Anything special about it?
        Well, it is possible that any calculations using FP performed on an impacted kernel may need to be redone, and any results re-validated. And while, typically, the (targeted) scientific/engineering calculations where the results that can really matter are checked, double checked, and triple checked, repeatedly, there may be some exceptions.

        Comment


        • #5
          Thanks Michael! I asked for a patch yesterday and you have it today!

          Now that's service ...

          Comment


          • #6
            Originally posted by timofonic View Post
            Another bug fix. Anything special about it?
            The kernel fudging fp-regs is a very severe bug. So yes, very special.
            It's not like some remote tidbit driver nobody cares about.
            I'm very surprised that the fallout has been so "tiny".

            Comment


            • #7
              Originally posted by milkylainen View Post
              I'm very surprised that the fallout has been so "tiny".
              we don't actually know that the fallout has been tiny:

              Originally posted by CommunityMember View Post
              Well, it is possible that any calculations using FP performed on an impacted kernel may need to be redone, and any results re-validated.

              Comment


              • #8
                Originally posted by CommunityMember View Post

                Well, it is possible that any calculations using FP performed on an impacted kernel may need to be redone, and any results re-validated. And while, typically, the (targeted) scientific/engineering calculations where the results that can really matter are checked, double checked, and triple checked, repeatedly, there may be some exceptions.

                In practice, does anyone actually do numerical calculations in Golang?

                Comment


                • #9
                  Originally posted by jacob View Post
                  In practice, does anyone actually do numerical calculations in Golang?
                  this bug doesn't only affect Go. it was just noticed first in Go. anyone doing AVX computations on a kernel with the bug could be affected (incorrect results) without having noticed yet.

                  Comment


                  • #10
                    This bug is not just triggered by doing just any AVX work.

                    It requires (from here):
                    1. A thread doing AVX operations using YMM registers.
                    2. A signal where the kernel must fault in stack pages to write the signal context.
                    3. Context switches. Having a single task isn't sufficient.

                    Comment

                    Working...
                    X