> 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.
utrace_set_events() can, yes. I think the old code ju
> Not sure this makes real sense, but perhaps it would be tidier to
> check QUIESCE in utrace_resume.
I think the theory was that getting there without it set would be very
unlikely. That wasn't really true with the report-on-attach behavior.
But it should be without that (read on). OTOH, the bi
> Ah. Why, why I have not thought of it?
Your mind is filled with the actual hard parts, that's why! :-)
I'm only dabbling enough to make the obvious suggestions.
> Agreed... ptrace_set_events? I agree with any naming.
Sure. I'm not really picky either, I just hate the stupid __ names.
Anythin
> However I was looking if there were reasons why "interrupt" from a
> tracing thread would be preferred over a "queued signal"?
This is the fundamental point of requesting utrace reports (either
UTRACE_REPORT or UTRACE_INTERRUPT)--the tracer gets control before any
user-visible action can happen.
Not sure this makes real sense, but perhaps it would be tidier to
check QUIESCE in utrace_resume.
I wonder if we still have reasons to set ->report + TIF_NOTIFY_RESUME
in utrace_add_engine(). Looks like this is not needed now, but I am
not sure.
Signed-off-by: Oleg Nesterov
---
kernel/utrace.c
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 w
Now that we don't use "ptrace & PT_" we can kill ptrace_setoptions()
and ptrace_update_utrace().
We could also remove all PT_ defines except PT_PTRACED and PT_PTRACE_CAP.
---
kernel/ptrace.c | 73
1 file changed, 73 deletions(-)
--- PU
Convert ptrace.c to use context->options.
I guess ptrace_report_clone() still needs changes... bbut hopefully
ptrace_clone_attach() is fine.
---
--- PU/kernel/ptrace.c~21_USE_CTX_OPTS 2009-09-04 18:01:09.0 +0200
+++ PU/kernel/ptrace.c 2009-09-04 18:33:03.0 +0200
@@ -204,7 +204,
Roland McGrath wrote:
>
> IMHO the traditional PT_* bit assignments are useless.
> We should just store and use the PTRACE_O_* bits directly.
Agreed!
---
kernel/ptrace.c | 28 +++-
1 file changed, 3 insertions(+), 25 deletions(-)
--- PU/kernel/ptrace.c~20_DONt_USE_PT_
Finish this change...
Now we should change ptrace_set_action()/etc to use ptrace_context,
and start some functional changes.
But I encountered the problem, see patch 23.
Oleg.
On 09/04, Roland McGrath wrote:
>
> > Add "int options" into struct ptrace_context. Will be used to hold
> > PT_XXX options. Currently is not used, but:
>
> IMHO the traditional PT_* bit assignments are useless.
> We should just store and use the PTRACE_O_* bits directly.
Ah. Why, why I have not t
We are pleased to announce the availability of the following customer lists:
Informatica
Documentum
Remedy
Patrol
MQ Software
Microsoft Sharepoint
Lotus Connections
Primavera
Microsoft Project
ATG
Websphere Commerce
Netsuite
Click Commerce
Sterling Commerce
Biztalk
FRX
CRM
System Center
Visual Stud
On 09/04, Ananth N Mavinakayanahalli wrote:
>
> I prefer Roland's ops->release approach.
Yes! me too.
> However, is there any chance
> that ->ops is no longer valid
Sure, ->ops can be changed at "any time". For example, just because of
UTRACE_DETACH.
That is why utrace_attach_task() saves ->rel
On Fri, Sep 04, 2009 at 02:55:29AM -0700, Roland McGrath wrote:
> > Simple answer. Because I do not know how to implement this. At least now.
> > I tried to think of this more, but I don't see how to make the first steps.
> >
> > (Yes, to be honest, this looks like "unnecessary complication" to me
Hi Roland, Oleg
I hit upon a case where a traced thread steps over a inserted breakpoint
instruction, and the tracing engine requests the traced thread to be
interrupted. Here the traced thread calls report_signal callback with
UTRACE_REPORT_SIGNAL and later does a report_signal callback with
UTRA
> Simple answer. Because I do not know how to implement this. At least now.
> I tried to think of this more, but I don't see how to make the first steps.
>
> (Yes, to be honest, this looks like "unnecessary complication" to me, I have
> to admit. But this is not the reason.)
Well, I am befuddled
> I need to re-check this, but iirc this hook is not needed at all since
> "[PATCH 10] ptrace_report_clone: rework auto-attaching".
It certainly should never be needed in the clean version of reality.
Thanks,
Roland
> Add "int options" into struct ptrace_context. Will be used to hold
> PT_XXX options. Currently is not used, but:
IMHO the traditional PT_* bit assignments are useless.
We should just store and use the PTRACE_O_* bits directly.
> - introduce __ptrace_set_options() helper which updates ->option
I merged these. My review nits you can follow up on at your leisure.
Thanks,
Roland
Sorry for the delay. I merged those 3 patches.
Thanks,
Roland
Do singlestep post processing only when we are sure to have singlestepped.
When there are multiple engines, we cannot rely on signal_action to be
passed unchanged to report_signal callback of subsequent engines.
Relying on signal_action and info->si_signo can lead to uprobes
singlestepping when we
This patch fixes the leak in uproc refcount when a tracing thread does
defer_registration.
When threads queue defer_registration, uprobes was leaking uproc
refcount. If a tracing process requested a [un]register operation that
was defered, then subsequent removal of all probes would still keep
Redo report_signal callback().
1. Ensure we dont mistake signal_action just because another engine's
report_signal callback has messed with UTRACE_SIGNAL_REPORT. i.e check
orig_ka.
2. gdbstub works similarly irrespective of the order of the engines
attached. If gdbstub attaches to a process thats
Hi Frank, Utrace-devel
The first two patches in this patchset fix report_signal callbacks in
uprobes and gdbstub.
>From Rolands message to utrace-devel,
https://www.redhat.com/archives/utrace-devel/2009-August/msg00146.html
we could rely on orig_ka == NULL to know if info->si_signo field for
sig
24 matches
Mail list logo
