Bug 10848

Summary:	enforcement of memory limits
Product:	systemtap	Reporter:	Frank Ch. Eigler <fche>
Component:	runtime	Assignee:	David Smith <dsmith>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	P2
Version:	unspecified
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:
Bug Depends on:
Bug Blocks:	10907

Description Frank Ch. Eigler 2009-10-26 16:17:05 UTC

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

Comment 1 David Smith 2009-12-09 16:42:05 UTC

(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.

Comment 2 David Smith 2010-01-05 21:37:03 UTC

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.

Comment 3 Frank Ch. Eigler 2010-01-15 08:50:12 UTC

(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.

Comment 4 Frank Ch. Eigler 2010-01-15 20:01:48 UTC

I believe the basic needs are fulfilled.