[PATCH] mm: Add config option for default panic_on_oom value

[PATCH] mm: Add config option for default panic_on_oom value

[Eddie James]

Add the option to kconfig and set the default panic_on_value.

Signed-off-by: Eddie James <eajames@linux.ibm.com>
---
 mm/Kconfig    | 7 +++++++
 mm/oom_kill.c | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/mm/Kconfig b/mm/Kconfig
index 675a6be43739..1fde865b0a63 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -825,6 +825,13 @@ config ZSMALLOC_STAT
 config GENERIC_EARLY_IOREMAP
 	bool
 
+config PANIC_ON_OOM_DEFAULT
+	int "Startup setting for panic_on_oom"
+	default 0
+	range 0 2
+	help
+	  This is the default startup value for /proc/sys/vm/panic_on_oom
+
 config STACK_MAX_DEFAULT_SIZE_MB
 	int "Default maximum user stack size for 32-bit processes (MB)"
 	default 100
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 3996301450e8..a6a9cc5635f8 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -52,7 +52,7 @@
 #define CREATE_TRACE_POINTS
 #include <trace/events/oom.h>
 
-static int sysctl_panic_on_oom;
+static int sysctl_panic_on_oom = CONFIG_PANIC_ON_OOM_DEFAULT;
 static int sysctl_oom_kill_allocating_task;
 static int sysctl_oom_dump_tasks = 1;
 
-- 
2.27.0

Re: [PATCH] mm: Add config option for default panic_on_oom value

[Andrew Morton]

On Wed, 11 May 2022 13:34:00 -0500 Eddie James <eajames@linux.ibm.com> wrote:

> Add the option to kconfig and set the default panic_on_value.

Why?  What are the use-cases and how does this benefit our users?

Re: [PATCH] mm: Add config option for default panic_on_oom value

[Eddie James]

On 5/11/22 16:56, Andrew Morton wrote:
> On Wed, 11 May 2022 13:34:00 -0500 Eddie James <eajames@linux.ibm.com> wrote:
>
>> Add the option to kconfig and set the default panic_on_value.
> Why?  What are the use-cases and how does this benefit our users?

If a distribution (for example some embedded system distribution) wants 
the system to always panic when OOM, they may as well configure their 
kernel to do it by default, rather than writing to 
/proc/sys/vm/panic_on_oom every boot. Maybe I'm missing another way to 
do what I want here?


Thanks,

Eddie

Re: [PATCH] mm: Add config option for default panic_on_oom value

[Andrew Morton]

On Wed, 11 May 2022 17:06:35 -0500 Eddie James <eajames@linux.ibm.com> wrote:

> 
> On 5/11/22 16:56, Andrew Morton wrote:
> > On Wed, 11 May 2022 13:34:00 -0500 Eddie James <eajames@linux.ibm.com> wrote:
> >
> >> Add the option to kconfig and set the default panic_on_value.
> > Why?  What are the use-cases and how does this benefit our users?
> 
> If a distribution (for example some embedded system distribution) wants 
> the system to always panic when OOM, they may as well configure their 
> kernel to do it by default, rather than writing to 
> /proc/sys/vm/panic_on_oom every boot. Maybe I'm missing another way to 
> do what I want here?

Presumably such a distribution would do this in initramfs initscripts
and forget about it.

What inspired the patch?  Have you seen a situation which was best
solved with this change?

Re: [PATCH] mm: Add config option for default panic_on_oom value

[Eddie James]

On 5/11/22 17:36, Andrew Morton wrote:
> On Wed, 11 May 2022 17:06:35 -0500 Eddie James <eajames@linux.ibm.com> wrote:
>
>> On 5/11/22 16:56, Andrew Morton wrote:
>>> On Wed, 11 May 2022 13:34:00 -0500 Eddie James <eajames@linux.ibm.com> wrote:
>>>
>>>> Add the option to kconfig and set the default panic_on_value.
>>> Why?  What are the use-cases and how does this benefit our users?
>> If a distribution (for example some embedded system distribution) wants
>> the system to always panic when OOM, they may as well configure their
>> kernel to do it by default, rather than writing to
>> /proc/sys/vm/panic_on_oom every boot. Maybe I'm missing another way to
>> do what I want here?
> Presumably such a distribution would do this in initramfs initscripts
> and forget about it.


Yes, my thinking was that it was either a line in an init script or a 
system service. It seems more efficient to configure it in the kernel 
instead.


>
> What inspired the patch?  Have you seen a situation which was best
> solved with this change?


Yes, our distro, OpenBMC, uses systemd, so I thought we'd need a new 
service. However after a little more research, I see now that that the 
existing systemd-sysctl can do what you suggest and set it during early 
boot. So that is probably the right way to go, and this change can be 
dropped.

Thanks for your feedback!

Eddie


>