This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Fixed PR13146 by not allowing memory allocations to sleep (Was: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-1.6-151-g8e794e9)
- From: Jim Keniston <jkenisto at linux dot vnet dot ibm dot com>
- To: David Smith <dsmith at redhat dot com>
- Cc: Josh Stone <jistone at redhat dot com>, Mark Wielaard <mjw at redhat dot com>, systemtap at sourceware dot org
- Date: Wed, 05 Oct 2011 08:23:43 -0700
- Subject: Re: Fixed PR13146 by not allowing memory allocations to sleep (Was: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-1.6-151-g8e794e9)
- References: <20110901143940.13672.qmail@sourceware.org> <1317135124.3361.22.camel@springer.wildebeest.org> <4E82481E.8060502@redhat.com> <1317164453.3979.9.camel@localhost> <4E8C5FC3.6070007@redhat.com>
On Wed, 2011-10-05 at 08:46 -0500, David Smith wrote:
> On 09/27/2011 06:00 PM, Jim Keniston wrote:
>
> > I haven't seen this explicitly mentioned wrt this thread or PR13146, but
> > uprobes and uretprobe handlers (which are called from the utrace
> > report_signal callback) can sleep.
>
>
> Jim,
>
> For my information, can uprobe/uretprobe handlers sleep in the new
> uprobes being proposed upstream?
I think yes. But sorry, I've been out of the loop on Srikar's uprobes
implementation for quite a while, so you'll have to ask him.
Wrt uretprobes, I've seen a draft implementation a while back, but I
haven't noticed it being posted to LKML.
> (Note that in the new utrace-less task_finder I'm working on, handlers
> can't sleep since they get called from a tracepoint, whose handlers
> can't sleep.)
>
Jim