Date:	Wed, 01 Apr 2009 13:40:24 -0400
From:	Masami Hiramatsu <mhiramat@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	systemtap-ml <systemtap@...rces.redhat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jim Keniston <jkenisto@...ibm.com>
Subject: Re: [PATCH -tip 0/4 V3] tracing: kprobe-based event tracer

Ingo Molnar wrote:
> * Masami Hiramatsu <mhiramat@...hat.com> wrote:
> 
>> Ingo Molnar wrote:
>>> * Masami Hiramatsu <mhiramat@...hat.com> 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.
>>
>> https://www.redhat.com/archives/utrace-devel/2009-March/msg00031.html
> 
> 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.

Thanks,

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

e-mail: mhiramat@...hat.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists