Re: [PATCH -tip 0/4 V3] tracing: kprobe-based event tracer

Masami Hiramatsu
2009-04-01T17:40:41Z

Ingo Molnar wrote:
> * Masami Hiramatsu <mhiramat@redhat.com> wrote:
>
>> Ingo Molnar wrote:
>>> * Masami Hiramatsu <mhiramat@redhat.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