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

Ingo Molnar
2009-04-01T13:37:46Z

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

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.

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

So please lets do this now, it needs to happen.

Not having this was the main design failure of original kprobes,
this fragility is what isolated kprobes from the rest of the
instrumentation world and made it essentially a SystemTap-only
special. And this problem is fixable.

It does not have to be a full solution, but it has to be a pretty
safe one. If it's safe and there are no showstopper objections from
others we can apply it to -tip

Can you see any fundamental reason why this couldnt be done?

Thanks,

Ingo