RE: x86_64 kprobes wart removal

["Chen, Brad" <brad dot chen at intel dot com>]

I asked a few folks around here about this thread and they 
did have a few thoughts on this subject (below). Hopefully 
we will start hearing more from these guys soon...

Brad 


Will have to really look at kprobe in kernel to see what things are
going on there.  But few important points that are worth mentioning here
(without going in complete context):

-1 allocating a memory in get_insn_slot should be avoided as much as
possible (dunno if this could be happening in interrupt context or
not...if it could then don't use mem allocation).  These kind of
functionalities should/could be handled not at per arch level.

2- XD is present now even on IA-32 systems.  So the execute only issue
is not only limited to x86_64.

3- Don't try to acquire a lock before single stepping any instruction.
....this is unnecessary bottleneck on bigger machines that should be
avoided.

4- vmalloced memory could be used for single step.  As said above, this
needs to be architeced for all the archs.

5- In general any updates to code pages (or its permissions) need to be
strictly following set of architected (both kernel and HW) sequences.

6- The much I'm thinking, I'm not liking the single step part in
accomplishing the operation here....quite possible I don't have the
complete picture here.


> -----Original Message-----
> From: systemtap-owner@sources.redhat.com
> [mailto:systemtap-owner@sources.redhat.com] On Behalf Of Jim Keniston
> Sent: Thursday, April 07, 2005 3:02 PM 
> To: SystemTAP
> Subject: x86_64 kprobes wart removal
> 
> This email is for x86_64 kprobes wonks.  Remember get_insn_slot() and
> free_insn_slot()?  These functions are a constant headache because
> they 
> can sleep.  That's because get_insn_slot() occasionally has to
> allocate 
> a readable, writable, executable page to hold the instruction-copy
> for a 
> new kprobe.  That's because x86_64 won't single-step (or otherwise
> execute) an instruction on a page that isn't mapped executable.
> 
> I propose the following alternative:
> - Allocate one executable page at the beginning of time. [See note 1.]
> - Store the instruction copy in the kprobe object, as in other
> arhcitectures.
> - When it comes time to single-step an instruction, just copy the
> instruction from the kprobe object to the executable page.
> - In resume_execution, adjust copy_rip accordingly.
> 
> Note 1: If we go to per-CPU locking, we may need to allocate enough
> space for NR_CPUS instructions.  Also, we still want to use Roland's
> trick of allocating the memory close to where the modules live.
> 
> I don't have a patch yet, but does that sound like the right approach?
> I wish I'd thought of this a year ago. :-}
> 
> Jim