init_module may pin a lot of memory if given a bogus size
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Incomplete
|
Low
|
Thadeu Lima de Souza Cascardo | ||
stress-ng (Ubuntu) |
Fix Released
|
Low
|
Colin Ian King |
Bug Description
When running stress-ng sysinval stressor, I got a panic from an unrecoverable OOM.
This happens because stress-ng will call init_module with a module length of INT_MAX and that will allocate that much memory with vmalloc, which is not accountable for the process. This memory is freed by using vfree right after that, but when you run 4 to 8 stressors on a VM with ~8GiB of RAM, that might trigger OOM and there will be no way to recover, causing a panic.
Using __GFP_RETRY_MAYFAIL for both init_module and kernel_read_file (called by finit_module), alleviates the problem, but does not solve it, as other allocators will trigger OOM.
Module loading is an operation that is considered trusted, so it will be hard to do many changes in that path, so we might consider not stressing the system like that in our testing.
Cascardo.
Changed in stress-ng (Ubuntu): | |
assignee: | nobody → Colin Ian King (colin-king) |
Changed in linux (Ubuntu): | |
assignee: | nobody → Thadeu Lima de Souza Cascardo (cascardo) |
Changed in stress-ng (Ubuntu): | |
importance: | Undecided → Low |
Changed in linux (Ubuntu): | |
importance: | Undecided → Low |
This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:
apport-collect 1906447
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the Ubuntu Kernel Team.