> Yes. But finish_callback() can race with utrace_set_events() which can
> clear QUIESCE after the callback returns UTRACE_SINGLESTEP, in this case
> the warning is wrong.
Ah! I see your point.
Thanks,
Roland
On 08/19, Oleg Nesterov wrote:
>
> If ->vfork_stop was set, it was set by us, no need to take utrace->lock
> to check it.
Oh. Yes, but...
I hope I missed something, but I'm _afraid_ we may have problems.
Looks like we can almost never use utrace->xxx:1 fields without ->lock.
Suppose that, for ex
If ->vfork_stop was set, it was set by us, no need to take utrace->lock
to check it.
Signed-off-by: Oleg Nesterov
---
kernel/utrace.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
--- PU/kernel/utrace.c~UTRACE_1_vfork_stop 2009-08-19 14:00:57.0
+0200
+++ PU/kerne
commit bd86cff51a2f221b6cb10649212e5392aea7bcb7
Author: Srikar Dronamraju
Date: Wed Aug 19 11:43:53 2009 +0530
We only need to intimate gdb once if we get multiple requests for look
There can be multiple stop requests before gdb gets control. However continue
from gdb can resulting in the proc
commit 90cc0931707c99459aea0f6601d7f5ce2756dbd8
Author: Srikar Dronamraju
Date: Wed Aug 19 10:26:00 2009 +0530
While releasing, unregister uprobes if any after detach
Currently because of the way uprobes works, (register/unregister may
deadlock if one of the threads of this process is expectin
commit bf679f65284b834b455e8453d10616073ff58d2c
Author: Srikar Dronamraju
Date: Tue Aug 18 18:15:49 2009 +0530
detach fix
Saw a Oops message
BUG: unable to handle kernel NULL pointer dereference at 0018
IP: [] get_utrace_lock+0x43/0x115
I figured out the reason for the oops mes
This patch modifies report_signal callback for gdbstub and
uprobe_handler.
Previously we would alert in uprobe_handler that gdb should stop the
thread. For this we expected the thread to stop before it singlestepped.
However this seems unreliable and also we werent doing a explicit
UTRACE_STOP.
Hi Frank,
Please review the set of patches for gdbstub.
These are based on your maintained tree.
utrace-next/utrace-gdbstub-uprobes branch.
(1afe698c3228e67c43db6343b383a13e27e7f11a)
I have explicitly run checkpatch.pl to remove any formatting warnings /
errors. However the formatting in thes
Change ptrace_report_clone() to do all attach work itself. Note that this
allows to greatly simplify do_fork() path wrt tracehooks. For example we
do not need tracehook_prepare_clone() at all. tracehook_finish_clone()
does not need tasklist. copy_process() does not need "int traced".
Both ptrace_r
Until we kill ->ptrace, attach must ensure ->ptrace == 0 to avoid the
races with detach. We can move these checks to ptrace_attach_task()
from the callers, and we can do this check lockless.
>From now ptrace_abort_attach() is only called when the tracee had no
chance to execute any callback, a sim
I was going to do this later. But since I didn't find a simple
solution for engine->data problems yet (and to be honest I hope
the discussion about engine->realease is not finished ;), I am
sending these changes to make at least small progress.
Oleg.
On 08/18, Roland McGrath wrote:
>
> > > (or even just report_quiesce
> > > when passed UTRACE_EVENT(DEATH)) that always detaches.
> >
> > Hmm. Not sure I understand how can we do without hooking death or reap...
>
> UTRACE_EVENT(QUIESCE) constitutes "hooking death".
Ah yes, utrace_report_death() d
On 08/18, Roland McGrath wrote:
>
> > In particular, this means that
> >
> > if (event || (clone_flags & CLONE_PTRACE)) {
> > child_engine = utrace_attach_task(child, UTRACE_ATTACH_CREATE
> > ...
> >
> > is not right. CLONE_PTRACE should be ignored unless task_ptrace(current).
On 08/18, Roland McGrath wrote:
>
> > C recieves a signal, notices task_utrace_flags(), calls utrace_get_signal(),
> > dequeues the signal, calls E->ops->ptrace_report_signal() which returns
> > UTRACE_STOP.
>
> Your implementation of this can probably just use the same method as for a
> real PTRAC
On 08/18, Roland McGrath wrote:
>
> > Unfortunately, this doesn't help if a module doesn't use utrace_control()
> > but just returns UTRACE_SINGLESTEP/etc. Like Srikar's test-case does.
>
> Yes. I thought about adding a WARN_ON or something. But I think it would
> just wind up being confusing or
15 matches
Mail list logo
