> Thanks Roland. > > But now I am even more confused... I get that combination a lot! ;-)
Just to keep everyone confused, note that this thread now has approximately nothing to do with single-step. It really does have something to do with single-step, but only in the special sense of TIF_SINGLESTEP handling syscall exit, which is at low-level really more of a syscall-tracing situation than it is a single-step situation. It actually took me writing this paragraph to remember that this did have anything to do with single-step! > I am not sure... I can hardly read entry_64.S, but I am not sure > system_call_fastpath: path calls syscall_trace_leave() on exit... There are various paths to flag checks that cover TIF_SYSCALL_TRACE and TIF_SINGLESTEP (_TIF_WORK_SYSCALL_EXIT). But you are right, there is one path that skips that. I believe this can come up for vanilla ptrace only in one situation, and that case should probably be considered a bug. If you entered the syscall with TIF_SYSCALL_TRACE, then you wind up taking the int_ret_from_sys_call path out. In almost all the other cases that ptrace can see, you will wind up taking that path out too for other reasons. I think the only cases where you can have a ptrace stop followed by actually taking the ret_from_sys_call path are tracehook_report_clone stops (i.e. the stop inside a clone/fork/vfork syscall). If you last used PTRACE_CONT or whatever and then hit PTRACE_EVENT_FORK et al, resuming with PTRACE_SYSCALL will fail to hit the syscall-exit report for that fork/clone syscall. I added ptrace-tests/tests/syscall-from-clone.c for this case. As I thought from inspection, it fails on x86-64 but not on a 32-bit process. I'm also pretty sure (without having tested it) that it doesn't fail on a 32-bit kernel. It would be worthwhile to cons a version of this test case that uses PTRACE_SINGLESTEP instead of PTRACE_SYSCALL. I think your situation is tickling the same issue, but we should have an empirical test. > I used the vanilla kernel too. It doesn't work for me. Under KVM at least... I make no claims about KVM. It has not lacked for obscure bugs in the past. If the results are ever confusing, you should certainly compare the behavior of virtual and real machines to verify before you let it drive you insane. In this case, of course, it's just squirrely little assembly paths driving you insane, but, trust me, you'd feel robbed if you went this insane just because of a KVM bug! :-D I have a fix in hand that I'll send upstream before too long. But perhaps it should wait for the PTRACE_SINGLESTEP version of the test case. git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-roland.git branch x86/ptrace-syscall-exit > And there is another issue: finish_resume_report(UTRACE_RESUME) does > user_disable_single_step(). That is a separate issue, which is simply understanding the utrace API. The x86-64 bug above is real but unrelated. > Now I _hope_ I fully understand why my initial patch to handle > PTRACE_SINGLESTEP didn't work. report_signal/quiesce should re-assert > SINGLESTEP, it should be recorded in ptrace_context. Yes. That's largely what ptrace_set_action() et al was all about. Thanks, Roland
