This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: uprobes: keep thread blocked after the handler returns


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]