Description of problem:
On x86_64, processes randomly segfault
This is also a host bug, fixed during the 2.6.16 series. It appears that these segfaults were caused by ptraced system calls on x86_64 returning via sysret, rather than iret. sysret requires that the process preserve at least %RCX because the instruction uses that as the userspace address to resume. In the case of sigreturn, that's impossible since signals happen asynchronously to the process. So, ptracing sigreturn will cause %RCX to be changed, and that seems to be the cause of the random process segfaults.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run a user mode linux guest on a kernel < 2.6.16 under an x86_64 arch
2. Run any significant program (like mandb -c)
3. Watch the program segfault
Programs in the guest OS segfault
Programs should not segfault
UML = user mode linux
Note that the fix for this problem caused another, noted on the same page:
'handle_trap - failed to wait at end of syscall'
The full panic is
Kernel panic - not syncing: handle_trap - failed to wait at end of
syscall, errno = 0, status = 2943
This is a host bug introduced during the 2.6.16 series which broke ptrace. In the course of fixing a different bug (see the random segfault problem below), ptrace returned two system call return notifications rather than the one it's supposed to. It's fixed in 2.6.16-rc6, so upgrade the host to at least that.
A proper backport should fix both (or fix the first without introducing the second)
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life.
Please See https://access.redhat.com/support/policy/updates/errata/
If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.