Re: 2.4 Ready list - Kernel Hooks

[Werner Almesberger <wa@almesberger.net>]

Richard J Moore wrote:
>>EXPORT_SYMBOL_GPL.
> 
> 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
better.

> 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         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/