lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 12 May 2022 09:01:34 -0500
From:   Eddie James <eajames@...ux.ibm.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: Add config option for default panic_on_oom value


On 5/11/22 17:36, Andrew Morton wrote:
> On Wed, 11 May 2022 17:06:35 -0500 Eddie James <eajames@...ux.ibm.com> wrote:
>
>> On 5/11/22 16:56, Andrew Morton wrote:
>>> On Wed, 11 May 2022 13:34:00 -0500 Eddie James <eajames@...ux.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


>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ