mbox series

[00/21] linux-user: Move signal trampolines to new page

Message ID 20210616011209.1446045-1-richard.henderson@linaro.org
Headers show
Series linux-user: Move signal trampolines to new page | expand

Message

Richard Henderson June 16, 2021, 1:11 a.m. UTC 
It is my guess that the majority of the flakiness with the
linux-user signals.c test is due to a race condition between
translation and page writes.  I vaguely recall a bug report
about this, but I cannot find it now.

Since the vast majority of "self-modifying code" is due to
signal delivery, work around this by allocating a new page,
into which we write the signal handlers.

A better workaround would be to implement the vdso that is
required by many guests.  However, that is a much larger
problem, and some guests do not define a vdso in upstream
linux.  This serves as a decent fallback.

Neither bit of work, I will note, solves the posited race
condition described above.


r~


Richard Henderson (21):
  linux-user: Add infrastructure for a signal trampoline page
  linux-user/aarch64: Implement setup_sigtramp
  linux-user/arm: Force v2 frames for fdpic
  linux-user/arm: Implement setup_sigtramp
  linux-user/alpha: Implement setup_sigtramp
  linux-user/cris: Implement setup_sigtramp
  linux-user/hexagon: Implement setup_sigtramp
  linux-user/hppa: Document non-use of setup_sigtramp
  linux-user/i386: Implement setup_sigtramp
  linux-user/m68k: Implement setup_sigtramp
  linux-user/microblaze: Implement setup_sigtramp
  linux-user/mips: Implement setup_sigtramp
  linux-user/nios2: Document non-use of setup_sigtramp
  linux-user/openrisc: Implement setup_sigtramp
  linux-user/ppc: Implement setup_sigtramp
  linux-user/riscv: Implement setup_sigtramp
  linux-user/s390x: Implement setup_sigtramp
  linux-user/sh4: Implement setup_sigtramp
  linux-user/sparc: Implement setup_sigtramp
  linux-user/xtensa: Implement setup_sigtramp
  linux-user: Remove default for TARGET_ARCH_HAS_SIGTRAMP_PAGE

 linux-user/aarch64/target_signal.h    |   2 +
 linux-user/alpha/target_signal.h      |   1 +
 linux-user/arm/target_signal.h        |   2 +
 linux-user/cris/target_signal.h       |   2 +
 linux-user/hexagon/target_signal.h    |   2 +
 linux-user/hppa/target_signal.h       |  14 ++
 linux-user/i386/target_signal.h       |   2 +
 linux-user/m68k/target_signal.h       |   2 +
 linux-user/microblaze/target_signal.h |   2 +
 linux-user/mips/target_signal.h       |   1 +
 linux-user/mips64/target_signal.h     |   2 +
 linux-user/nios2/target_signal.h      |   3 +
 linux-user/openrisc/target_signal.h   |   2 +
 linux-user/ppc/target_signal.h        |   2 +
 linux-user/qemu.h                     |   7 +
 linux-user/riscv/target_signal.h      |   2 +
 linux-user/s390x/target_signal.h      |   2 +
 linux-user/sh4/target_signal.h        |   2 +
 linux-user/sparc/target_signal.h      |   4 +
 linux-user/x86_64/target_signal.h     |   3 +
 linux-user/xtensa/target_signal.h     |   2 +
 linux-user/aarch64/signal.c           |  28 ++--
 linux-user/alpha/signal.c             |  34 +++--
 linux-user/arm/signal.c               | 190 +++++++++++++++-----------
 linux-user/cris/signal.c              |  29 ++--
 linux-user/elfload.c                  |  13 ++
 linux-user/hexagon/signal.c           |  19 ++-
 linux-user/i386/signal.c              |  42 +++---
 linux-user/m68k/signal.c              |  47 +++----
 linux-user/microblaze/signal.c        |  24 +++-
 linux-user/mips/signal.c              |  39 ++++--
 linux-user/openrisc/signal.c          |  24 ++--
 linux-user/ppc/signal.c               |  34 ++---
 linux-user/riscv/signal.c             |  22 +--
 linux-user/s390x/signal.c             |  24 ++--
 linux-user/sh4/signal.c               |  40 +++---
 linux-user/signal.c                   |   3 +
 linux-user/sparc/signal.c             |  32 +++--
 linux-user/xtensa/signal.c            |  50 ++++---
 39 files changed, 488 insertions(+), 267 deletions(-)

-- 
2.25.1

Comments

Alex Bennée June 16, 2021, 3:05 p.m. UTC | #1 
Richard Henderson <richard.henderson@linaro.org> writes:

> It is my guess that the majority of the flakiness with the

> linux-user signals.c test is due to a race condition between

> translation and page writes.  I vaguely recall a bug report

> about this, but I cannot find it now.

>

> Since the vast majority of "self-modifying code" is due to

> signal delivery, work around this by allocating a new page,

> into which we write the signal handlers.

>

> A better workaround would be to implement the vdso that is

> required by many guests.  However, that is a much larger

> problem, and some guests do not define a vdso in upstream

> linux.  This serves as a decent fallback.

>

> Neither bit of work, I will note, solves the posited race

> condition described above.


Well this certainly solves the failures I was seeing with
s390x-on-s390x:

  retry.py -n 500 -c -- ./qemu-s390x ./tests/tcg/s390x-linux-user/signals
  Results summary:
  0: 500 times (100.00%), avg time 2.253 (0.00 varience/0.00 deviation)
  Ran command 500 times, 500 passes

However qemu-hppa (on x86_64 host) still has the stuborn 1% failure rate
(-static build):

  Results summary:
  0: 198 times (99.00%), avg time 2.255 (0.00 varience/0.00 deviation)
  -4: 2 times (1.00%), avg time 0.252 (0.00 varience/0.00 deviation)
  Ran command 200 times, 198 passes

So have a:

Tested-by: Alex Bennée <alex.bennee@linaro.org>

(for s390x at least)

-- 
Alex Bennée
Richard Henderson June 16, 2021, 3:09 p.m. UTC | #2 
On 6/16/21 8:05 AM, Alex Bennée wrote:
> However qemu-hppa (on x86_64 host) still has the stuborn 1% failure rate...


Have a squizzle at patch 8.  I wasn't able to do anything with hppa yet.


r~