Precisando de servios ou Segurana ? acesse nossosite:www.guardia.com.br
Se no estiver visualizado a imagem, favor acessar o seguinte endereo:http://www.guardia.com.br/marketing/
ou nosso site: www.guardia.com.br
Clique Aqui para se descadastrar de nossa lista.
shouldn't copy_process() do clear_tsk_thread_flag(child, TIF_SINGLESTEP) ?
I'll recheck this, but looks like both upstream and utrace-ptrace
should do this. Otherwise, the new child can start with TIF_SINGLESTEP
copied from parent's ti-flags. This looks just wrong, but if we do not
auto-attach
It took me more time/efforts than I expected, and probably needs
more changes.
I still owe you review/fixes for utrace-cleanup branch.
Oleg.
As you suggested, we can simplify ptrace_request()-ptrace_resume()
path, ptrace_resume_action() checks all for resume requests except
PTRACE_CONT.
---
kernel/ptrace.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
---
Preparation, no functional changes.
- change ptrace_report_signal()-resume_signal() to clear ctx-signr,
not only ctx-siginfo. This allows us to overload ctx-signr.
IOW, with this patch ctx-signr != 0 is only possible when a tracee
is stopped with the valid ctx-siginfo after reporting the
Move send_sigtrap() logic from ptrace_resume() to ptrace_report_signal().
ptrace_resume() sets ctx-signr = SIGTRAP and returns UTRACE_INTERRUPT.
ptrace_report_signal() notices SIGTRAP, fills *info and reports the signal.
fill_sigtrap_info() mimics x86-specific send_sigtrap(), therefore:
Suppose that a PTRACE_O_TRACEFORK tracee does fork() and stops in
SYSCALL_ENTRY state. The tracer does PTRACE_SINGLESTEP.
In this case the tracee resumes and stops after syscall_trace_leave()
to report PTRACE_EVENT_FORK, but since it passes syscall_trace_leave()
with TIF_SINGLESTEP set the tracee
