Re: 2.4 Ready list - Kernel Hooks

From: Werner Almesberger (
Date: Wed Oct 23 2002 - 14:50:09 EST

Richard J Moore wrote:
> We already do that.

Oops, missed that one, sorry ! I was looking at the interface
functions, but making the hooks themselves GPL-only is even

> I don't envisage having an arbitrary set of hook points scattered
> throughout the kernel.

Let's hope you're right :-)

But wouldn't a small extension of kprobes get you pretty much
the same functionality/performance:

- at busy attachment points, add a "kprobe anchor", which
  translates to five NOPs [1,2], preceded by a global symbol
- when setting a kprobe, check if the five bytes starting
  at p->addr are NOPs [3]
- if yes, insert a call to kprobes_fastpath. if not, use
  the current double breakpoint mechanism
- kprobes_fastpath can just return to the caller, no code
  modification or single-stepping required

[1] Assuming i386.
[2] Or any sufficiently unlikely sequence of instructions that
    executes faster than NOPs.
[3] Or some other pattern - but a quick look at the kernel binary
    suggests that all strings of five or more NOPs are used for
    padding between function, so it would be safe to assume that
    any such sequence is a basic block.

The advantage over hooks would be that users of this mechanism
wouldn't have to choose between fast but intrusive (hooks) and
slow but flexible (probes).

Now, it's non-trivial to do a "return from caller" with
[kd]probes. I haven't looked at that part yet. Do you have the
infrastructure for this ?

- Werner

 / Werner Almesberger, Buenos Aires, Argentina /
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 22:01:05 EST