I seem to find the problem, and I do not see a simple solution.
Will try to think more tomorrow with a fresh head, but perhaps
you can help. looks like we need some changes in utrace/signal
layer.
Suppose that a tracee is going to report, say, PTRACE_EVENT_FORK.
The callback returns UTRACE_STOP.
Misc changes, more preparations for ptrace_report_signal().
Oleg.
Kill the now unneeded code.
From now -ptrace is only used for PT_PTRACED and PT_PTRACE_CAP.
---
kernel/ptrace.c | 281 +---
1 file changed, 6 insertions(+), 275 deletions(-)
--- PU/kernel/ptrace.c~44_KILL_OLD_CODE 2009-09-16
SIGKILL can be already dequeued if we are called from do_exit() path.
This debugging check should die, but I'd like to keep it for now.
---
kernel/ptrace.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- PU/kernel/ptrace.c~45_STOP_WARNINGS 2009-09-17 17:54:06.0 +0200
+++
The multi-line utrace_attach_task(a lot of args) looks really annoing,
add the trivial helper, ptrace_lookup_engine(tracee).
---
kernel/ptrace.c | 32 +---
1 file changed, 13 insertions(+), 19 deletions(-)
--- PU/kernel/ptrace.c~48_PTRACE_LOOKUP_ENGINE 2009-09-17
I am worried about PTRACE_SYSEMU, I continue to ignore this magic
which I don't understand yet... Hopefully I will be able to add the
necessary changes later.
It should not be a big complexity. The semantics is that the entry report
always does like UTRACE_SYSCALL_ABORT to skip the actual
do_ptrace_notify_stop() doesn't change -ptrace_message if the new
value is zero. Not sure what I was thinking about when I wrote this.
Perhaps you were thinking of the upstream code before tracehook.h was
introduced. Ancient code left whatever was in ptrace_message before there
for the 0
I am a bit surprised there is nothing in ptrace-tests to check
CONT/SYSCALL behaviour. I had to write this one:
That suite has grown only through regression tests for bugs that we've
noticed. So it doesn't test a case if my past implementations never broke
that case, nor if a regression never
ptrace_report_clone() still needs more changes. I think it is simple to
fix it now, but can't we simplify the utrace's behaviour first?
utrace_report_clone() does not set utrace-vfork_stop without CLONE_VFORK,
this adds some complications. Perhaps we can kill CLONE_VFORK check?
Please
