This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: Hitachi djprobe mechanism
- From: Richard J Moore <richardj_moore at uk dot ibm dot com>
- To: Keshavamurthy Anil S <anil dot s dot keshavamurthy at intel dot com>
- Cc: Keshavamurthy Anil S <anil dot s dot keshavamurthy at intel dot com>, Mathieu Desnoyers <compudj at krystal dot dyndns dot org>, Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>, Karim Yaghmour <karim at opersys dot com>, Masami Hiramatsu <masami dot hiramatsu at gmail dot com>, michel dot dagenais at polymtl dot ca, Roland McGrath <roland at redhat dot com>, Satoshi Oshima <soshima at redhat dot com>, sugita at sdl dot hitachi dot co dot jp, systemtap at sources dot redhat dot com
- Date: Fri, 29 Jul 2005 00:47:03 +0100
- Subject: Re: Hitachi djprobe mechanism
- Sensitivity:
There are more efficient ways of implementing a jmp type hook - see the
kernel hooks package, where we evloved past this string of 5 no-ops
implementation Here we moved an immediate value - 1 byte - into a reg and
jumped on the reg being non-zero. To spring the hook we stored the one
immediate byte in the mov instruction. This technique works quite well on
IA64 where one can use a predicate register for the same purpose.
- -
Richard J Moore
IBM Advanced Linux Response Team - Linux Technology Centre
MOBEX: 264807; Mobile (+44) (0)7739-875237
Office: (+44) (0)1962-817072
Keshavamurthy
Anil S
<anil.s.keshava To
murthy@intel.co Mathieu Desnoyers
m> <compudj@krystal.dyndns.org>
cc
28/07/2005 Keshavamurthy Anil S
21:34 <anil.s.keshavamurthy@intel.com>,
Karim Yaghmour <karim@opersys.com>,
Masami Hiramatsu
Please respond <masami.hiramatsu@gmail.com>, Masami
to Hiramatsu
Keshavamurthy <hiramatu@sdl.hitachi.co.jp>, Roland
Anil S McGrath <roland@redhat.com>, Richard
J Moore/UK/IBM@IBMGB,
systemtap@sources.redhat.com,
sugita@sdl.hitachi.co.jp, Satoshi
Oshima <soshima@redhat.com>,
michel.dagenais@polymtl.ca
bcc
Subject
Re: Hitachi djprobe mechanism
On Thu, Jul 28, 2005 at 02:32:36PM -0400, Mathieu Desnoyers wrote:
> The goal of this int3 is indeed that, if another thread on another CPU
falls
> into it, the int3 handler will change its own return address to fall into
the
> push instruction, right after the nops.
Ah..I see you point now.
>
> For the IPI :
>
> - the on_each_cpu should be called from a context where no spinlock is
held. The
> context from which it is called could be protected by a flag which
would cause
> any concurrent processor to fail if they try to follow the same "code
> alteration" function.
> - the IPI handler does not need to spin at all. It just returns. It only
has to
> inform us about when interrupt disabled zone has ended. As this zone
will not
> be reentered due to the int3 instruction, everything is fine.
If we are not spinning in IPI then I am fine.
>
> Or did I miss something ?
However I have one more issues to mentioni(for discussion sake), when we
have several nop
instructions(may be 4 nop instruction) in a landing zone, we have no
guarantee that
all of these nop instructions are with in a page boundary. This is very
important
because when you replace these instruction with a 5 byte jump instruction,
this
5 byte jump instruction should be with in a page boundary else the
processor
will generate unaligned instruction access voilation or it might
generate page fault while trying to execute an instruction which is a very
bad thing.
How are we going to address this issues?
Thanks,
Anil