This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: uprobes: keep thread blocked after the handler returns
- From: Octavian Purdila <tavi at cs dot jhu dot edu>
- To: "David J. Wilder" <dwilder at us dot ibm dot com>
- Cc: systemtap at sourceware dot org
- Date: Fri, 3 Aug 2007 00:17:43 +0300
- Subject: Re: uprobes: keep thread blocked after the handler returns
- Organization: JHU
- References: <200708022342.34434.tavi@cs.jhu.edu> <46B24784.8010900@us.ibm.com>
On Friday 03 August 2007 00:07, David J. Wilder wrote:
> Octavian Purdila wrote:
> > Hi all,
> >
> > Is there a way to keep the thread blocked after the uprobe handler
> > returns? The scenario in which this can be usefull is when we want to do
> > the probing from userspace.
> >
> > I know it can be done with utrace, but I think is more convenient to do
> > it directly from uprobes.
> >
> > Thanks,
> > tavi
>
> Why not just prevent the handler from returning until you want the
> thread to unblock? The handler could sleep on something trigger from
> user space.
If I understand it correctly, the uprobe handler runs from an utrace handler.
And utrace documentation says that while you are allowed to sleep for short
amounts of time in it's handlers, if you want to sleep for large amounts of
time you should use the quiescent feature.
To make my question/comment clear, what I would like to have, is the ability
to keep the thread in the quiescent thread after returning from the uprobe
handler.
Would something as simple as changing the uprobe's handler type to
int (*uprobe_handler_t)(struct uprobe*, struct pt_regs*);
and then propagating the return value from the uprobe handler to the utrace
handler work? (i.e. when I want to keep the thread quiescent, return from the
uprobe handler with UTRACE_ACTION_QUIESCE)
Thanks,
tavi