mm/Kconfig | 7 +++++++ mm/oom_kill.c | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-)
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
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?
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
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?
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 >
© 2016 - 2026 Red Hat, Inc.