I noticed you didn't apply
[PATCH 23] ptrace_attach_task: kill WARN_ON(err) (perhars we can
improve ->reporting logic?)
https://www.redhat.com/archives/utrace-devel/2009-September/msg00038.html
I am resending it as 83.
ptrace_attach_task:
engine = utrace_attach_task(CREATE | EXCLUSIVE);
err = utrace_set_events();
WARN_ON(err && !tracee->exit_state);
Looks correct but it is not. utrace_attach_task() can return EINPROGRESS.
Note that start_callback/etc sets ->reporting = engine even if we are not
going to call ->report_any().
This WARN_ON() was always wrong, even without multitracing, even without
recent changes which introduced reusing.
Consider: the tracer exits and does implicit detach when the tracee has
already called, say, utrace_resume(). The new tracer attaches, the tracee
does list_for_each_entry()->start_callback(). start_callback() sets
->reporting = new_engine even if engine->flags = 0.
I'd prefer to just kill this WARN_ON, but you prefer to keep this warning
https://www.redhat.com/archives/utrace-devel/2009-September/msg00043.html
OK, please see the patch.
But I have to admit, I dislike this WARN_ON() in ptrace_attach_task().
First, it needs the comment to explaint why EINPROGRESS is OK.
But more importantly, WARN_ON(err && err != -EINPROGRESS && !tracee->exit_state)
equally applies to any usage of utrace_set_events(), no? If this warning
is useful, then perhaps we should move it into utrace_set_events() ?
---
kernel/ptrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- PU/kernel/ptrace.c~83_ATTACH_SUPPRESS_WARNING 2009-10-12
17:46:11.000000000 +0200
+++ PU/kernel/ptrace.c 2009-10-12 17:50:36.000000000 +0200
@@ -490,7 +490,7 @@ finish:
* must notice this before setting PT_PTRACED.
*/
err = __ptrace_set_options(tracee, engine, options);
- WARN_ON(err && !tracee->exit_state);
+ WARN_ON(err && err != -EINPROGRESS && !tracee->exit_state);
utrace_engine_put(engine);
return 0;
}
