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: [RFC] Design + prototype: Multiple kprobes at an address - take2


Frank Ch. Eigler wrote:
On Wed, Apr 06, 2005 at 02:11:39PM -0400, Ananth N Mavinakayanahalli wrote:

[...]

By the way, why is complete disarming (removal) deemed the appropriate
response to reentrant probes?  What would go wrong if a nested kprobe
call would be only ignored somehow, and go right to the
single-stepping of its target instruction?  [...]

How/when will you reset the re-entry flag to revoke suspension and start processing the probes as normal? How/when do you know it is safe to do so?


Perhaps when the outer kprobe pre/post handler has returned?

But how can we deem it is safe to do so? Needs more thought...


[...]

What can a custom kprobes fault handler do if a user-level instruction
causes a fault?  [...]

If you look at the notifier hooks that invoke the fault handler, they are only at the entry of the page_fault and general protection paths, and are used to shield the kernel from seeing this fault if caused by the probes. [...]


Yes, "caused by the probes" i.e., providing protection to buggy
pre/post handlers.  What I don't understand (and rereading Richard's
message didn't help) is how *single-stepping the user code* could
trigger a fault, and do so in such a way that the kprobes-registered
handler could do something useful with it.

Is the idea that the single-stepped user instruction would e.g.,
perform memory access to an address that happens to be paged out, to
cause an ordinary page fault?  OK, so you don't want the kernel to
process that as a page fault right there because of the int3 context
(right?).  I can imagine this happening, but what could a user-defined
kprobes handler do to the user program to let it recover?

Yes, that is the idea, and as Richard mentions, the fault handler could
disarm the probe and pretend no probe had been installed and let the kernel handle the rest.


Thanks,
Ananth


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