This is the mail archive of the systemtap@sources.redhat.com 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: reentrant probes


Prasanna S Panchamukhi <mailto:prasanna@in.ibm.com> wrote on Tuesday,
May 03, 2005 5:10 AM:
>>> 
>>> I think it will be quite useful to allow renentrancy in probes.  Not
>>> sure why would you want to restrict this.
> 
> Reentrancy can be provided, by just disarming the probes temperoraly
> and rearming it after the pre/post handler are done.

Seems like you are trying to ensure that more than 1 probe is not active
at any time.  And this is really not providing reentrency.  Besides the
limited stack space (and cyclic dependency), what are the other issues
that you are worried about.

> This involves following steps.
> 
> Detecting that another probe is being hit while handling a current
probe. 
> Disarm the new probe by writting the original instruction back within
> the interrupt handler.  Remove the kprobe from the kprobes list and
add it 
> to disarm list.
> 

How do you think this will pan out on SMP.  The way I look at it, you
are basically disabling the probe from the all the CPUs....all of which
may not have context of any other probe at that time.

Rewriting the instruction back and forth opens lot of risky race
conditions that will result in lot more house keeping in kernel.  For
example, how will you ensure that other CPUs are not seeing any partial
or stale updates in original code location.

> Queue the work thread to the workqueue for rearming the probe.
> Since flushing the instruction cache within the interrupt handler is
> not safe, we queue the work to be handled outside the interrupt
context.
> The worker thread just rearms it by writting int3. Also removes the
kprobe from
> the  disarm list and adds it to the kprobes list.
> 
> But there will a small window between the probe being disarmed and
> rearmed, were the disarmed probes will be missed.
> 


I like this idea of arming and disarming the probes.  Though it will be
nice to have this through /proc or some such user interface.  A user
should be able to specify which probes need to be disarmed/deactivated
temporarily (without unregistering them).  I think it also will be
useful to let user (probe writer) specify if a specific probe is to be
marked not reentrant.  And in this case, basically you don't execute the
pre and post handler.  The original instruction will execute as part of
int3 handling.

-rohit


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