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: x86_64 kprobes wart removal


On Fri, 2005-04-08 at 16:57, Chen, Brad wrote:
> 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...

Thanks.  See below.

> 
> 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).

No, not in interrupt context.  Not with a lock held, either, ideally. 
Getting the latter right has been a problem recently; hence my proposal.

> 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.

This is a bigger kprobes issue.  I think a per-CPU lock is being
considered.

> 
> 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.

Specific suggestions are welcome, of course.

> 
> 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.

Again, a bigger kprobes issue.  Single-stepping the probed instruction
is Standard Operating Procedure for debuggers, as far as I know.  The
kprobes policy of single-stepping a COPY of the instruction is necessary
to avoid other CPUs missing the probepoint while kprobes fiddles with
the probed instruction.

Thanks again.
Jim


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