When I specified larger value than main memory, to -s option of systemtap, the system ran OOM killer and stopped on ia64 and x86-64. I couldn't reproduce it on ia32 because it's vmalloc-space is smaller than real memory. For example, if the machine has 4GB memory, run # stap -e 'probe begin{hello}' -s 4095 this causes OOM kill. if the machine has 8GB memory and 4 CPUs, run # stap -e 'probe begin{hello}' -s 2048 -b This is always reproducible on 64-bit arch. I think stap should fail to run if the system doesn't have enough free memory.
Users in stapusr group can cause OOM killer, because the size of relayfs is just a runtime option of staprun.
Perhaps relay_open* could be taught to use GFP_ATOMIC | GFP_NORETRY.
(In reply to comment #2) > Perhaps relay_open* could be taught to use GFP_ATOMIC | GFP_NORETRY. Indeed. However, we'd better care older kernel too, because relay will be replaced by new unified trace buffer. What about checking free memory by using si_meminfo()?
Created attachment 3056 [details] [PATCH] checking free memory before allocating relay buffer This patch adds free memory checking before allocation of relay in utt.c. There are 3 cases; 1. relaybuf < free, utt allows to allocate relay buffer. 2. free < relaybuf < free+buffered, utt warns and allocates relay buffer. 3. free+buffered < relaybuf, utt rejects allocation. 'free' is free memory, and 'buffered' is the memory which is used for io buffer.
Patch committed as 214b2c3.