Unsafe mode for probes

[Arkady <arkady dot miasnikov at gmail dot com>]

Hi,

I think that I have mentioned the problem before. I allocate
significant amount of virtual memory and create a shared memory
between my kernel drivers and code running in the user space. The goal
of the shared memory is to improve the throughput of the data channel
between the systemtap driver and the rest of the system.

I started by using 'probe begin' to call my C initialization code.
This approach expectedly failed.

My next step was a small kernel module which only initializes the
shared memory. Finally
I have patched the systemtap by adding two hooks
stp_user_init()/stp_user_close()  in
emit_module_init()/emit_module_exit() in the translate.cxx See, for
example, https://github.com/larytet/SystemTap/commit/6e4c99f96c9ecce9508f2c8612e8bace2ac91ae5
This worked just fine.

Still performance wise the driver is not where I would like it to be.
I collect majority of the system calls  and install 100+ probes. The
code has to stand in tight performance constraints. I improve the
performance further by replacing the most frequently called probes
generated by the systemtap by custom C code. Every time the systemtap
version/kernel version changes I have to rewrite the probes. I do not
want to drop the systemtap because the framework solves lot of
compatibility related problems.

I think to extend the STAP language by adding an "unsafe probe" - a
probe implemented in C. Unsafe probes do not enforce any checks. The
framework will "emit" access to the system call arguments and compile
the code. The framework will use the original stack for the local
variables.

I understand that this is a long way from the SystemTap stated
intention of the system debug. I am breaking quite a few core
assumptions. Indeed I use the SystemTap to implement a high
performance system audit for Linux.

I appreciate any feedback

Thank you