This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH] Kprobe:multi kprobe posthandler for booster
- From: Masami Hiramatsu <hiramatu at sdl dot hitachi dot co dot jp>
- To: Andrew Morton <akpm at osdl dot org>
- Cc: "mao, bibo" <bibo dot mao at intel dot com>, systemtap at sources dot redhat dot com
- Date: Thu, 27 Apr 2006 20:21:06 +0900
- Subject: Re: [PATCH] Kprobe:multi kprobe posthandler for booster
- References: <1146043305.29114.23.camel@maobb.site> <20060426145508.4d0b7537.akpm@osdl.org>
Hi, Andrew
Andrew Morton wrote:
> OK... But you didn't provide me with sufficient information with which I
> can gauge the seriousness of this problem. Show-stopper bug? Minor
> performance problem? Hard to tell, and I do need that information to be
> able to judge whether patches should do into -rc or into the next kernel
> cycle, as well as being backported into -stable.
I'm sorry not to provide detail information.
I described it below.
> I currently have four patches:
>
> kprobe-boost-2byte-opcodes-on-i386.patch
This is an enhancement patch of kprobe-booster on i386.
In the previous patch
(http://marc.theaimsgroup.com/?l=linux-kernel&m=114104159911612&w=4),
I decided that the first booster patch didn't boost the 2bytes
opcodes and prefixes, because of simplicity of the patch.
In this patch, I identified "boostable" 2 byte instructions as below;
- Conditional jumps can not be boost.
- WRMSR, RDMSR, CPUID, RSM, and RDPMC may have unexpected side effects.
Thus these can not be boost.
- Extended Groups are including some undefined opcodes. Thus
these can not be boost.
- Invalid opcode, UD2 and other undefined opcodes can not be boost.
- other defined opcodes can be boost.
I also identified prefixes again:
- Address size prefix(0x67) and CS segment override(0x2e) may change
valid address range. So these can not be boost.
- If there is other prefixes, there is a chance to boost it.
> kprobe-fix-resume-execution-on-i386.patch
This patch enables kprobe's resume_execution() to handle
iret(0xcf) and absolute-call(0x9a) correctly.
It handles those operations as below;
- iret
After the "iret" was executed, the value of eip register
was restored from the stack. Thus resume_execution() handles
it as same as "ret".
- absolute-call
The target address of the "absolute-call" is specified as an
absolute address. Thus no need to fix eip.
Best regards,
--
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: hiramatu@sdl.hitachi.co.jp