Re: [PATCH 0/1] Was: utrace-cleanup branch

On 11/12, Oleg Nesterov wrote: On 11/12, Roland McGrath wrote: I did some tweaks that I think address the several things you've raised. But I didn't try to reply point by point. I've merged everything up now, so the utrace-cleanup branch is gone. Please review the current code and

Re: [PATCH 127] move ptrace_resume()-send_sigtrap() logic into ptrace_report_signal()

Nothing wrong (I think), but this is more complex and implies more unnecessary work. You mean the code path taken is longer. But the code's logic remains simple. If ptrace_report_signal() sends the trap, we actually send the signal twice. Firstly ptrace_resume() does

[PATCH 130] revert turn PTRACE_EVENT_SIGTRAP into PTRACE_EVENT_SIGNAL

By the previous discussion, revert 603e19c41ba5c97e48a25543c63c081c5fe64137 for now. But keep WARN_ON(resume != XXX_STEP), it may help. --- kernel/ptrace.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) --- PU/kernel/ptrace.c~130_REVERT_KILL_PTRACE_EVENT_SIGTRAP

[PATCH 131] don't send the unnecessary SIGTRAP after SYSCALL_EXIT

PTRACE_SINGLESTEP after syscall-exit shouldn't trigger the trap before return to user-mode. This was the x86 spicific oddity which is already fixed in -mm by ptrace-x86-change-syscall_trace_leave-to-rely-on-tracehook-when-stepping.patch --- kernel/ptrace.c |6 ++ 1 file changed, 2

[PATCH 132] change ptrace_report_signal() to use user_single_step_siginfo()

Change ptrace_report_signal() to report SIGTRAP via user_single_step_siginfo() + force_sig_info(). --- kernel/ptrace.c | 24 +--- 1 file changed, 9 insertions(+), 15 deletions(-) --- PU/kernel/ptrace.c~132_USER_SINGLE_STEP_INFO2009-11-13 22:35:40.0 +0100