[Bug 219399] System panics after several hours of 14-threads-compilation orgies using poudriere on AMD Ryzen...

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399

--- Comment #195 from commit-hook at freebsd.org ---
A commit references this bug:

Author: truckman
Date: Wed Aug  2 01:43:36 UTC 2017
New revision: 321899
URL: https://svnweb.freebsd.org/changeset/base/321899

Log:
  Lower the amd64 shared page, which contains the signal trampoline,
  from the top of user memory to one page lower on machines with the
  Ryzen (AMD Family 17h) CPU.  This pushes ps_strings and the stack
  down by one page as well.  On Ryzen there is some sort of interaction
  between code running at the top of user memory address space and
  interrupts that can cause FreeBSD to either hang or silently reset.
  This sounds similar to the problem found with DragonFly BSD that
  was fixed with this commit:
   
https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/b48dd28447fc8ef62fbc963accd301557fd9ac20
  but our signal trampoline location was already lower than the address
  that DragonFly moved their signal trampoline to.  It also does not
  appear to be related to SMT as described here:
   
https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads?p=955498#post955498

    "Hi, Matt Dillon here. Yes, I did find what I believe to be a
     hardware issue with Ryzen related to concurrent operations. In a
     nutshell, for any given hyperthread pair, if one hyperthread is
     in a cpu-bound loop of any kind (can be in user mode), and the
     other hyperthread is returning from an interrupt via IRETQ, the
     hyperthread issuing the IRETQ can stall indefinitely until the
     other hyperthread with the cpu-bound loop pauses (aka HLT until
     next interrupt). After this situation occurs, the system appears
     to destabilize. The situation does not occur if the cpu-bound
     loop is on a different core than the core doing the IRETQ. The
     %rip the IRETQ returns to (e.g. userland %rip address) matters a
     *LOT*. The problem occurs more often with high %rip addresses
     such as near the top of the user stack, which is where DragonFly's
     signal trampoline traditionally resides. So a user program taking
     a signal on one thread while another thread is cpu-bound can cause
     this behavior. Changing the location of the signal trampoline
     makes it more difficult to reproduce the problem. I have not
     been because the able to completely mitigate it. When a cpu-thread
     stalls in this manner it appears to stall INSIDE the microcode
     for IRETQ. It doesn't make it to the return pc, and the cpu thread
     cannot take any IPIs or other hardware interrupts while in this
     state."
  since the system instability has been observed on FreeBSD with SMT
  disabled.  Interrupts to appear to play a factor since running a
  signal-intensive process on the first CPU core, which handles most
  of the interrupts on my machine, is far more likely to trigger the
  problem than running such a process on any other core.

  Also lower sv_maxuser to prevent a malicious user from using mmap()
  to load and execute code in the top page of user memory that was made
  available when the shared page was moved down.

  Make the same changes to the 64-bit Linux emulator.

  PR:           219399
  Reported by:  nbe at renzel.net
  Reviewed by:  kib
  Reviewed by:  dchagin (previous version)
  Tested by:    nbe at renzel.net (earlier version)
  MFC after:    2 weeks
  Differential Revision:        https://reviews.freebsd.org/D11780

Changes:
  head/sys/amd64/amd64/elf_machdep.c
  head/sys/amd64/amd64/initcpu.c
  head/sys/amd64/include/md_var.h
  head/sys/amd64/linux/linux_sysvec.c

-- 
You are receiving this mail because:
You are the assignee for the bug.