Re: utrace_report_syscall_entry() finish_report()

2009-11-12 Thread Oleg Nesterov
On 11/11, Roland McGrath wrote: I saw you have utrace-syscall-resumed branch but never looked at it. For those not concerned with its purpose, there is one thing you must know. Every report_syscall_entry callback must do: if (utrace_syscall_action(action) == UTRACE_SYSCALL_RESUMED)

Re: utrace_report_syscall_entry() finish_report()

2009-11-12 Thread Roland McGrath
Simple example. The tracee stopped in syscall-entry. the tracer does PTRACE_SINGLESTEP. With the recent changes in utrace-cleanup utrace_control() doesn't set TIF_SINGLESTEP, and the tracee passes syscall_trace_leave() without TIF_SINGLESTEP. Ah, yes. Well, the point of the arch/tracehook

Re: utrace_report_syscall_entry() finish_report()

2009-11-11 Thread Oleg Nesterov
On 11/10, Roland McGrath wrote: Ok. I realize it's largely separate, but I think we want to hash through this along with the other set of after-report-behavior problems. Also, it doesn't seem sensible to fiddle with utrace_report_syscall_entry separate from resolving UTRACE_SYSCALL_RESUMED

Re: utrace_report_syscall_entry() finish_report()

2009-11-11 Thread Roland McGrath
I saw you have utrace-syscall-resumed branch but never looked at it. For those not concerned with its purpose, there is one thing you must know. Every report_syscall_entry callback must do: if (utrace_syscall_action(action) == UTRACE_SYSCALL_RESUMED) return

Re: utrace_report_syscall_entry() finish_report()

2009-11-10 Thread Roland McGrath
Ok. I realize it's largely separate, but I think we want to hash through this along with the other set of after-report-behavior problems. Also, it doesn't seem sensible to fiddle with utrace_report_syscall_entry separate from resolving UTRACE_SYSCALL_RESUMED change to the API. There was not