| Summary: | Systemtap will causes OOM when specifying large relay buffer size. | ||
|---|---|---|---|
| Product: | systemtap | Reporter: | Masami Hiramatsu <mhiramat> |
| Component: | runtime | Assignee: | Masami Hiramatsu <mhiramat> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
| Attachments: | [PATCH] checking free memory before allocating relay buffer | ||
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. |
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.