[lkml]   [2009]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH -tip 0/4 V3] tracing: kprobe-based event tracer
Ingo Molnar wrote:
> * Masami Hiramatsu <> wrote:
>> Ingo Molnar wrote:
>>> * Masami Hiramatsu <> wrote:
>>>> Hi,
>>>> Here are the patches of kprobe-based event tracer for x86, version
>>>> 3. Since this feature seems to attract some developers, I'd like
>>>> to push these basic patches into -tip tree so that they can easily
>>>> play it.
>>>> This version supports only x86(-32/-64) (If someone is interested
>>>> in porting this to other architectures, I'd happy to help :)), and
>>>> no respawn-able probe support (this would be better to push -mm
>>>> tree.)
>>>> This can be applied on the linux-2.6-tip tree.
>>> This bit:
>>>> Future items:
>>>> - Check insertion point safety by using instruction decoder.
>>> is i believe a must-fix-before-merge item.
>> Hi Ingo,
>> I agreed. Fortunately, Jim Keniston and I wrote an x86 instruction
>> decoder :-) which has been made originally for uprobe andd kprobes
>> jump-optimizer.
> looks cool. Needs to be put somewhere in arch/x86/lib/, provided as
> a generic facility, with a Kconfig variable that says that the
> architecture supports it and then the kprobes-tracer could make
> immediate use of it, right?

Yeah, I'd rather add a safety checker in kprobes-x86 itself, because
sometimes it has to fixup instructions modified by previous kprobes.


>>> The functionality is genuinely useful, and if used dynamically on
>>> the host it can be a lot more versatile and a lot more accessible
>>> than a KGDB session - but code patching safety is a must-have.
>>> It does not have to be a full decoder, just a simplified decoding
>>> run that starts from a known function-symbol address, and works its
>>> way down in the function looking at instruction boundaries, and
>>> figuring out whether the code patching is safe. If it sees anything
>>> it cannot deal with it bails out.
>> Yeah, that is what I'll do.
>>> I suspect you could get very good practical results by supporting
>>> just a small fraction of the x86 instruction set architecture. If
>>> failures to insert a probe safely are printed out in clear terms:
>>> Could not insert probe at address 0xc01231234 due to:
>>> Unknown instruction: 48 8d 15 db ff ff ff 00 00 00
>>> People will fill in the missing ISA bits quickly :-)
>>> And people doing:
>>> asm(" .byte 0x00, 0x01, 0x02, 0x03;"); /* hehe, I broke the decoder! */
>>> ... in kernel .text functions will be talked to in private :)
>> Aha, that function will get illegal instruction exception :-) even
>> without kprobe.
> Not if it's under a never-true (not provable to the compiler) branch
> condition but i digress :)
>>> Can you see any fundamental reason why this couldnt be done?
>> Nope, because we've done :-)
> Cool :)
> Ingo

Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division


 \ /
  Last update: 2009-04-01 19:43    [W:0.101 / U:0.008 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site