linux-kernel - Re: [PATCH] mm/oom_kill: add sysctl_oom_dump_stack to control kernel stack dumping on OOM

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]

Message-ID: <bf31a8f0-4e33-15bc-d3d5-6c81aae5b07a@google.com>
Date: Sat, 13 Dec 2025 17:55:34 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Michal Hocko <mhocko@...e.com>
cc: Yang Xin <yx.0xffff@...il.com>, akpm@...ux-foundation.org, 
    shakeel.butt@...ux.dev, linux-mm@...ck.org, linux-kernel@...r.kernel.org, 
    Yang Xin <redleaf@...ux.alibaba.com>
Subject: Re: [PATCH] mm/oom_kill: add sysctl_oom_dump_stack to control kernel
 stack dumping on OOM

On Thu, 11 Dec 2025, Michal Hocko wrote:

> On Fri 12-12-25 04:24:33, Yang Xin wrote:
> >     Most OOM kills triggered by user-space processes produce kernel stack
> >     traces that are not helpful for diagnosing the root cause. These traces
> >     usually just show the page fault handler or system call entry.
> > 
> >     Furthermore, dump_stack() can be expensive. It often runs with
> >     interrupts disabled or holds the console lock for a long time,
> >     potentially causing system latencies and preventing the system from
> >     responding to other events.
> > 
> >     This patch adds a new sysctl vm.oom_dump_stack to control this
> >     behavior. Writing '0' to /proc/sys/vm/oom_dump_stack suppresses the
> >     kernel stack dump during OOM kills, while '1' (the default) preserves
> >     the existing behavior.
> 
> While I fundamentally do not object to ways to suppress stacks traces
> for OOM I would really like to hear more what kind of overhead we are
> talking about here (stack traces are reported for tracing and other low
> latency situations) and why does this matter for as cold of a path as
> OOM is.
> 
> Also we are getting way too many of these sysctls. Maybe it is time to
> look for a more customizable way to configure oom output that doesn't
> require sysctl per output feature.
> 

Strongly agree, I don't think this requires yet another sysctl.  It's also 
global, so it will affect all oom kills including the ones where you might 
find a stack to actually be really helpful to understand the issue.