So (!entryexit & regs->gprs < 0) translates to the debugger changed theI don't think, it hurts. If a debugger willingly sets the syscall number
system call to something illegal on the first of the two ptrace calls. So
patch doesn't hurt for normal, non-ptraced operation but it might hurt
users of ptrace.
Ok, I think I've understood the problem now. What you are basically have isThis other signal must be pending on the *host*, in UML, this might be
a process running in a UML guest that happens to have -ERESTARTXXX in grp2
when it gets interrupted. A signal is delivered and on return from that
with sys_(rt_)sigreturn >another< signal might be pending and then
gets confused because of -ERESTARTXXX in grp2.
For normal, non-uml operationMy idea was to enable the existing ptrace interface to do what UML
restore_sigregs resets regs->trap to -1 which avoids the confusion. With
the host intercepts sys_rt_sigreturn and does whatever needs to be done for
the guest >except< resetting regs->trap to -1. So the problem seems to be
that you need a ptrace interface to do that. I don't think it is a good
to kludge syscall_trace to reset regs->trap under some conditions.