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: Hitachi djprobe mechanism


> Yes, slow is okay as long as you are *not* taking the full 
> system down during probe inserting/removal time. Halting full 
> system during probe insertion/removal might not be acceptable 
> at least on IA64.

This particular discussion has been entirely about picayune details of x86
instruction encoding (and x86-64).  So specific issues about other
architectures are really not apropos.  At any rate, I did not suggest
anything involving full-stop.

If I gleaned correctly from the discussion, the CPU bugs do not affect
single-byte int3 insertions.  We can presume they either don't or will be
fixed, since kprobes and all debuggers rely on that already.

What I was suggesting is as follows.  (This may well be exactly what
kerninst already did, it's been a while since I looked at those papers.)
This does not attempt to address the CONFIG_PREEMPT case.

Insert int3.  Use RCU to synchronize that all CPUs are executing after this
insertion.  This need not hold lots of locks or eat CPUs to synchronize, it
can just cause the probe inserter to sleep until RCU completes or suchlike.

At this point, you know that no CPU's PC can get into the probe-insertion
area without hitting the int3.  There is no danger of "half baked"
instruction decoding because any CPU getting there hits the breakpoint and
enters an explicit synchronization path through kprobes infrastructure code.  
A CPU that hits this breakpoint can either wait for the probe inserter to
finish, or it could just handle it in kprobes style and move on if the
instruction following the one copied by kprobes is outside the mutation area.

You store the remaining bytes of the probe jmp instruction.  Then store the
first byte, replacing the int3.  Then let any synchronized CPUs continue;
they could either resume kprobe-style processing, or back up the PC and
restart to allow the new probe-inserted jmp to happen.


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