It would be useful for a sysadmin to assert that a stap module (especially in unprivileged mode) not be allowed to consume more than some give MB of memory. This sort of thing could involve: - checking the .ko file at -p4 or -p5 time for ELF stats about .text/.data/.bss sizes, and comparing them to limits - perhaps teaching staprun to "create" free kernel memory (such as by creating a short-lived process that touches/consumes enough memory, then killing it just before the module_insert) - extending the _stp_*alloc functions to prematurely reject requests if limits are about to be exceeded - checking that every other use of kernel allocations go through _stp_alloc* - checking that all kernel-side memory allocations use __GFP_NORETRY or such to preclude triggering OOM handling elsewhere
(In reply to comment #0) > - checking that every other use of kernel allocations go through _stp_alloc* > - checking that all kernel-side memory allocations use __GFP_NORETRY or such > to preclude triggering OOM handling elsewhere Commit 965b658 makes sure all kernel-side memory allocations go through the _stp_alloc* functions (except for uprobes). The _stp_alloc* functions already used __GFP_NOTRETRY everywhere.
Commit de0c57f add a new #define to systemtap - MAXMEMORY. Here's the description: * If MAXMEMORY is defined to a value (stap -DMAXMEMORY=8192 ...) then * every memory allocation is checked to make sure the systemtap * module doesn't use more than MAXMEMORY of memory. MAXMEMORY is * specified in kilobytes, so, for example, '8192' means that the * systemtap module won't use more than 8 megabytes of memory. * * Note 1: This size does include the size of the module itself, plus * any additional allocations. * * Note 2: Since we can't be ensured that the module transport is set * up when a memory allocation problem happens, this code can't * directly report an error back to a user (so instead it uses * 'printk'). If the modules transport has been set up, the code that * calls the memory allocation functions * (_stp_kmalloc/_stp_kzalloc/etc.) should report an error directly wto * the user. * * Note 3: This only tracks direct allocations by the systemtap * runtime. This does not track indirect allocations (such as done by * kprobes/uprobes/etc. internals). This processing is not yet automatically turned on when in unprivileged mode.
(In reply to comment #2) > This processing is not yet automatically turned on when in unprivileged mode. It doesn't really have to be; the person who operates the stap-server instance that builds/signs unprivileged modules can add -DMAXMEMORY=foo to the stap-server command line as a prefix for all stap builds.
I believe the basic needs are fulfilled.