Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: Again: UML on s390 (31Bit) | From | Martin Schwidefsky <> | Date | Thu, 28 Apr 2005 15:03:17 +0200 |
| |
Bodo Stroesser <bstroesser@fujitsu-siemens.com> wrote on 04/28/2005 11:54:17 AM:
> > This patch is not good. !entryexit indicates that you want to change the trap > > indication on the first of the two calls of syscall_trace for a system call. The > > second condition is gprs[2] < 0 but that can be true for a normal system call as > > well, like sys_exit(-1). > Sorry, that's not right. At that point, gprs[2] holds the syscall number, while the > first argument of the syscall is in origgpr2. If the debugger sets the syscall number > to -1, which is an invalid syscall, changing trap to -1 will result in a changed > behavior only in case, that the debugger on the second syscall interception also sets > the syscall result to ERESTARTXXXXX (This again is modifying gprs[2]). ERESTARTXXXXX > normally would/could be handled by do_signal(), but with the patch it no longer will. > So, I think the patch doesn't hurt in normal cases, but does the trick for UML.
Yes, your are right. gprs[2] holds the syscall number for the debugger to change. So (!entryexit & regs->gprs[2] < 0) translates to the debugger changed the guest system call to something illegal on the first of the two ptrace calls. So the patch doesn't hurt for normal, non-ptraced operation but it might hurt other users of ptrace.
> > Independent from that it do not understand why you need it at all. If the > > uml host intercepted and invalidated the guest system call the system restart > > indication bit _TIF_RESTART_SVC shouldn't be set because the guest didn't > > execute a system call. > Let my explain a bit more. UML invalidates UML-user's syscalls on the host, processes > the syscall itself and inserts the result into gprs[2] on the second syscall > interception. For nearly all syscalls ERESTARTXXXXX is a result not returned to user, > but handled in UML kernel internally. But that's not true for sys_(rt_)sigreturn. > The "result" of those is the original contents of gpr2 of the interrupted routine, > which accidentally also might be ERESTARTXXXXXXX (BTW, that's the reason for > sys_(rt_)sigreturn setting trap to -1 also). We skip UML's syscall restart handling > in this case, but we need to skip it in the host, too.
Ok, I think I've understood the problem now. What you are basically have is 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 signal with sys_(rt_)sigreturn >another< signal might be pending and then do_signal gets confused because of -ERESTARTXXX in grp2. For normal, non-uml operation restore_sigregs resets regs->trap to -1 which avoids the confusion. With UML 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 idea to kludge syscall_trace to reset regs->trap under some conditions.
blue skies, Martin
Martin Schwidefsky Linux for zSeries Development & Services IBM Deutschland Entwicklung GmbH
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |