Found the trivial but nasty problem.
Ah! Good catch.
I added tracehook_init_task() in my tree. I don't see much benefit in
sending any tracehook patch upstream for this. tracehook_init_task()
corresponds to tracehook_free_task(), which is only added by utrace
(and both would just be empty in
On 11/18, Roland McGrath wrote:
I added tracehook_init_task() in my tree. I don't see much benefit in
sending any tracehook patch upstream for this. tracehook_init_task()
corresponds to tracehook_free_task(), which is only added by utrace
(and both would just be empty in a separate
On 11/18, Roland McGrath wrote:
Once again. The tracee sleeps in SYSCALL_ENTER. The tracer resumes
the tracee via utrace_control(UTRACE_SINGLESTEP).
Right. This is another strange corner. It doesn't necessarily make
especially good sense intrinsically for single-step to have this meaning
Just can't understand UTRACE_SYSCALL_RESUMED code.
To the pointed, I tried to read the docs:
* When %UTRACE_STOP is used in @report_syscall_entry, then @task
* stops before attempting the system call. In this case, another
* @report_syscall_entry callback follows after
On 11/16, Roland McGrath wrote:
You cited the one most obvious case: utrace_get_signal() has just run, so
finish_resume_report() has just run and everything is already as we want.
What else?
I think, we can say that finish_resume_report() must be never called
without reporting loop if
On top of your patch in
https://www.redhat.com/archives/utrace-devel/2009-November/msg00109.html
I attached this patch below just in case. As expected, it fixes
the problem with the lost TIF_SINGLESTEP.
Oleg.
--- UTRACE-PTRACE/kernel/utrace.c~__ROLAND_RESUME_FIX 2009-11-18
21:16:23.0
We should never call finish_resume_report(report) when
report-action == UTRACE_RESUME, this can destroy the result
of the previous finish_resume_report().
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/utrace.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
---
finish_report:
if (resume utrace-resume) {
spin_lock(utrace_lock);
utrace-resume = resume;
this can race with utrace_control().
If we are going to change utrace-resume we must always check it under
utrace-lock to ensure the new value is less than.
I'll reply tomorrow, it is to late for me.
But I noticed the funny detail in your email,
On 11/18, Roland McGrath wrote:
Yes. But, hmm.
utrace_stop(task, utrace, UTRACE_RESUME); /* XXX */
This XXX was there about passing UTRACE_RESUME, because that's not really
right.
I
