Roland, please ignore this and the next patch.
We can do the same without UTRACE_ATTACH_MATCH_CHECK.
I don't like to rely on -cred_guard_mutex, but MATCH_CHECK is
not nice too.
On 10/09, Oleg Nesterov wrote:
Implement UTRACE_ATTACH_MATCH_CHECK. With this flag utrace_attach_task(data)
data is
Please ignore
[PATCH 77] implement UTRACE_ATTACH_MATCH_CHECK
[PATCH 78] attach: try to re-use the self-detaching engine
patches.
Oleg.
[PATCH 76] fold detach_signal() into ptrace_detach_task() was buggy,
we read engine-date before checking IS_ERR(engine).
---
kernel/ptrace.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- PU/kernel/ptrace.c~79_FIX_DETACH_ENGINE_DEREF 2009-10-10
17:06:11.0 +0200
Change ptrace_attach_task() to re-use the self-detaching engine first,
then do utrace_attach_task(UTRACE_ATTACH_CREATE).
Unlike the previous version, ptrace_attach_task() just calls
ptrace_lookup_engine() and changes context-resume. The only caller
which can find the self-attaching engine is
Make sure that the new debugger doesn't get the old values in
ptrace_context or engine-flags if it re-uses the self-detaching
engine.
In particular, we should clear tracee-exit_code. The new debugger
should not see it via do_wait() until the tracee stops again. This
is racy, but -exit_code
Roland, Jan, what user-space expects ptrace(DETACH, SIGKILL) should do?
My guess: this should really kill the tracee asap, hence this patch.
---
kernel/ptrace.c |5 +
1 file changed, 5 insertions(+)
--- PU/kernel/ptrace.c~83_DETACH_SIGKILL2009-10-10 17:43:28.0
+0200
Issues with ptrace_check_attach(),
- it does utrace_control(UTRACE_STOP).
This is wrong, ptrace_check_attach() must be passive,
while utrace_control(UTRACE_STOP) can actualy stop the
tracee.
- even if it doesn't, this is wrong when we have multiple
On Sat, 10 Oct 2009 18:24:21 +0200, Oleg Nesterov wrote:
On 10/06, Jan Kratochvil wrote:
Yes, I agree with the current general behavior of ptrace there is missing:
if (WIFSTOPPED (status) WSTOPSIG (status) == SIGPIPE)
[...snip...]
--- attach-into-signal.c31 Jan 2009
On 10/10, Jan Kratochvil wrote:
On Sat, 10 Oct 2009 18:24:21 +0200, Oleg Nesterov wrote:
On 10/06, Jan Kratochvil wrote:
Yes, I agree with the current general behavior of ptrace there is missing:
if (WIFSTOPPED (status) WSTOPSIG (status) == SIGPIPE)
[...snip...]
On Sat, 10 Oct 2009 18:48:29 +0200, Oleg Nesterov wrote:
On 10/10, Jan Kratochvil wrote:
(VERBOSE-caught with FAIL now).
Cough. please translate this to me ;)
(Cc of each such mail to Roland does not look OK to me but removing Ccs is
also not OK)
--- tests/attach-into-signal.c 6 Oct 2009
On Sat, 10 Oct 2009 18:17:12 +0200, Oleg Nesterov wrote:
Roland, Jan, what user-space expects ptrace(DETACH, SIGKILL) should do?
My guess: this should really kill the tracee asap, hence this patch.
attached testcase works for me on both:
kernel-2.6.31.1-48.fc12.x86_64
On 10/10, Jan Kratochvil wrote:
On Sat, 10 Oct 2009 18:17:12 +0200, Oleg Nesterov wrote:
Roland, Jan, what user-space expects ptrace(DETACH, SIGKILL) should do?
My guess: this should really kill the tracee asap, hence this patch.
attached testcase works for me on both:
12 matches
Mail list logo
