kprobes problem

[Frank Ch. Eigler]

Hi -


wcohen wrote:

> [...] I was just figuring if we are fixing up the RET that we take a
> moment and make sure there are no other omissions.

Doing that may not be trivial, but here's another idea for a kprobes
stress-test.

1- write a tool that disassembles (via objdump?) the bulk of the kernel,
2- then translates that to a list of candidate instruction base addresses,
   perhaps a random subset, perhaps excluding known-risky sections (if any),
3- emits a kprobes module that inserts a dummy pre/post-handler function
   pair at all those addresses concurrently (or some random subset again)
4- load the module while keeping the kernel busy with a challenging workload
   like a benchmark or crashme
5- repeat from 2 or 3 until the kernel crashes
6- debug and start over

One could do the analogous test for jprobes / rprobes, just limiting
the list from #2 to function entry addresses.


- FChE