> There is one regression for PTRACE_SINGLESTEP on 2.6.28-rc7/8 + utrace.
Thanks for looking into this. > I made some analysis and found something. The main problem is in > ptrace_resume (kernel/ptrace.c). > > For ptrace(PTRACE_SINGLESTEP, child, 0, 0), we ran into > ptrace_resume. Then > > action: UTRACE_RESUME -> UTRACE_SINGLESTEP -> UTRACE_REPORT > > Next, utrace_control will let child resume freely. > > But for ptrace(PTRACE_SINGLESTEP, child, 0, SIGUSR1) (whatever data), > we ran in ptrace_resume > > action: UTRACE_RESUME -> UTRACE_SINGLESTEP -> UTRACE_REPORT -> > UTRACE_INTERRUPT > > utrace_control will resume child. Maybe there will be some other > actions. But child will be in step. The test can pass. What's supposed to happen is that ptrace_resume uses ptrace_set_action to store UTRACE_SINGLESTEP. It then actually passes UTRACE_REPORT or UTRACE_INTERRUPT to utrace_control (for the reasons explained in the comments in the code for each of those cases). The child should then get into either ptrace_report_quiesce or ptrace_report_signal (ptrace_resumed case). These both use ptrace_resume_action to extract what was saved by ptrace_set_action, which should still be UTRACE_SINGLESTEP. Then whichever of these callbacks it is should return that value, UTRACE_SINGLESTEP. It's that return value that is what should ensure that user_enable_single_step actually happens (in utrace.c:finish_resume_report). I'm not entirely sure I understood your description of what you see happening. But perhaps you can figure out exactly where it differs from what I've described that I think it should do. Thanks, Roland
