Skip to content

Conversation

edmonds
Copy link
Contributor

@edmonds edmonds commented Mar 3, 2021

The intent of the bcd_os_oom_adjust() function is apparently to disable OOM killing of the process, as it writes the value -17 to the /proc/<pid>/oom_adj path if it exists.

Per the kernel documentation:

For backwards compatibility with previous kernels, /proc/<pid>/oom_adj may also be used to tune the badness score. Its acceptable values range from -16 (OOM_ADJUST_MIN) to +15 (OOM_ADJUST_MAX) and a special value of -17 (OOM_DISABLE) to disable oom killing entirely for that task.

If /proc/<pid>/oom_adj does not exist, bcd_os_oom_adjust() attempts to write the same value (-17) to /proc/<pid>/oom_score_adj. This results in different behavior, because this value is within the OOM score adjustment range. Per the kernel documentation:

The value of /proc/<pid>/oom_score_adj is added to the badness score before it is used to determine which task to kill. Acceptable values range from -1000 (OOM_SCORE_ADJ_MIN) to +1000 (OOM_SCORE_ADJ_MAX). This allows userspace to polarize the preference for oom killing either by always preferring a certain task or completely disabling it. The lowest possible value, -1000, is equivalent to disabling oom killing entirely for that task since it will always report a badness score of 0.

Additionally, the bcd_os_oom_adjust() function attempts to write to /proc/<pid>/oom_adj and, if that path does not exist, falls back to writing to /proc/<pid>/oom_score_adj. On modern kernels where both paths exist, this results in a kernel warning being logged:

https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/fs/proc/base.c#L1074-L1080

This commit updates bcd_os_oom_adjust() to write "-1000" to /proc/<pid>/oom_score_adj first and, if that path does not exist, "-17" to the legacy /proc/<pid>/oom_adj path.

The intent of the bcd_os_oom_adjust() function is apparently to disable
OOM killing of the process, as it writes the value -17 to the
/proc/<pid>/oom_adj path if it exists.

Per the kernel documentation:

"For backwards compatibility with previous kernels, /proc/<pid>/oom_adj
may also be used to tune the badness score.  Its acceptable values range
from -16 (OOM_ADJUST_MIN) to +15 (OOM_ADJUST_MAX) and a special value of
-17 (OOM_DISABLE) to disable oom killing entirely for that task."

If /proc/<pid>/oom_adj does not exist, bcd_os_oom_adjust() attempts to
write the same value (-17) to /proc/<pid>/oom_score_adj. This results in
different behavior, because this value is within the OOM score
adjustment range. Per the kernel documentation:

"The value of /proc/<pid>/oom_score_adj is added to the badness score
before it is used to determine which task to kill.  Acceptable values
range from -1000 (OOM_SCORE_ADJ_MIN) to +1000 (OOM_SCORE_ADJ_MAX).  This
allows userspace to polarize the preference for oom killing either by
always preferring a certain task or completely disabling it.  The lowest
possible value, -1000, is equivalent to disabling oom killing entirely
for that task since it will always report a badness score of 0."

Additionally, the bcd_os_oom_adjust() function attempts to write to
/proc/<pid>/oom_adj and, if that path does not exist, falls back to
writing to /proc/<pid>/oom_score_adj. On modern kernels where both paths
exist, this results in a kernel warning being logged:

https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/fs/proc/base.c#L1074-L1080

This commit updates bcd_os_oom_adjust() to write "-1000" to
/proc/<pid>/oom_score_adj first and, if that path does not exist, "-17"
to the legacy /proc/<pid>/oom_adj path.
@sbahra sbahra merged commit a1df569 into backtrace-labs:master Dec 1, 2021
thatsafunnyname added a commit to thatsafunnyname/bcd that referenced this pull request Feb 9, 2024
Avoid overflow on "score" read buffer when set to "-17", when "write" is called.
Introduced in backtrace-labs@e5740aa from backtrace-labs#15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants