[RFC] Proposal of marker implementation

[Frank Ch. Eigler]

Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> writes:

> I'd like to suggest my marker idea which I spoke in OLS.
> My idea is based on the "section" of elf binary and the djprobe.

Clever.

> [...]  Each marker has 6bytes NOP. I think we can replace it with a
> jump code safely by using djprobe. [...]

If you don't use a call, is it still straightforward to eventually
return to the proper spot to resume execution?

> I think this marker has many advantages.
> - Minimal overhead (don't touch any memory if it is deactivated)

True.

> - Multiple markers can have the same name (we can activate those at once)

The same is true of the conditional-call markers.

> - There are no additional marking symbols in the kernel.

True, but this is not necessarily a good thing.  The conditional-call
markers keep kernel symbols so that no offline or debugging
information is needed to connect to them.

> - Easily extensible format (we can add some additional information in the section)

The same is true of the conditional-call markers.

> Also has some disadvantages.
> - Architecture dependency (but the "section" itself doesn't depend on the arch)

Indeed.

> - Need djprobe for safety (we can use kprobes until it goes fine)

Indeed.  Can djprobes do this kind of instruction replacement safely
for all kernel configurations (smp, preempt)?  I was under the
impression that there were unsolvable complications e.g. if the nops
span cache lines.

Another big disadvantage: no way to pass parameters.

- FChE