On 10/22, Roland McGrath wrote:
Hmm. If task is not stopped then it is current (except
utrace_control(DETACH) can play with the dying task).
Right, asynchronous detach was the problematic case I was concerned with.
but asynchronous detach doesn't do utrace_reset(), unless the tracee
is
The 1st patch I sent initially:
--- kstub/kernel/utrace.c~10_utrace_reset_should_clear_ss
2010-09-20 03:55:12.0 +0200
+++ kstub/kernel/utrace.c 2010-09-20 21:33:47.0 +0200
@@ -709,6 +709,7 @@ static bool utrace_reset(struct task_str
I think we should start with changing utrace_control(DETACH) anyway,
then try to improve. I'll ressend the one-liner I already showed.
Ok.
Hmm. I'll try to think more. Right now I don't really understand
how to do this correctly.
I wasn't immediately sure either.
OK,
On 09/21, Roland McGrath wrote:
OK, so what should we do for now?
If we can't come to a straightforward answer for the general case
fairly quickly, then we can do the simple change to start with.
I think we should start with changing utrace_control(DETACH) anyway,
then try to improve. I'll
On 09/23, Oleg Nesterov wrote:
On 09/21, Roland McGrath wrote:
It's better to have a spurious report (preferably just spurious
TIF_NOTIFY_RESUME with no actual callbacks) following any detach,
or whatever it takes to ensure user_disable_single_step() always
runs if user_enable_*_step
Change utrace_reset() to do user_disable_single_step(). Alternatively
we could change ptrace layer, but I think this is not ptrace specific.
Yes, it's right to fix this in the utrace layer.
But I'm not sure that's the right place in the code to fix it.
The expectation is that either we'll
On 09/21, Roland McGrath wrote:
Change utrace_reset() to do user_disable_single_step(). Alternatively
we could change ptrace layer, but I think this is not ptrace specific.
Yes, it's right to fix this in the utrace layer.
But I'm not sure that's the right place in the code to fix it.
The
On 09/21, Roland McGrath wrote:
I was worried about the case when the TIF_SINGLESTEP tracee detaches
itself and escapes finish_resume_report()-user_disable_single_step(),
say, utrace_report_exec(). But probably we can ignore this.
No, I think that is indeed a problem. If no engine is
On 09/22, Oleg Nesterov wrote:
On 09/21, Roland McGrath wrote:
I was worried about the case when the TIF_SINGLESTEP tracee detaches
itself and escapes finish_resume_report()-user_disable_single_step(),
say, utrace_report_exec(). But probably we can ignore this.
No, I think that is
OK, so what should we do for now?
If we can't come to a straightforward answer for the general case
fairly quickly, then we can do the simple change to start with.
Without the multitracing utrace_resume()-user_disable_single_step()
fixes the problem. Otherwise we probably need
Test-case:
#include stdio.h
#include signal.h
#include unistd.h
#include sys/ptrace.h
#include sys/wait.h
#include assert.h
int main(void)
{
int pid, status;
pid = fork();
if (!pid) {
On Mon, 20 Sep 2010 21:42:19 +0200, Oleg Nesterov wrote:
Test-case:
Checked in http://sourceware.org/systemtap/wiki/utrace/tests as step-detach.
Thanks,
Jan
12 matches
Mail list logo
