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

[Ingo Molnar]

* Masami Hiramatsu <mhiramat@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/