linux-kernel - Re: [RFT] sched_ext: Skip stack trace capture in NMI context

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251223153136.761d99af@gandalf.local.home>
Date: Tue, 23 Dec 2025 15:31:36 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Joel Fernandes <joelagnelf@...dia.com>
Cc: Tejun Heo <tj@...nel.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, David Vernet <void@...ifault.com>, Andrea
 Righi <arighi@...dia.com>, Changwoo Min <changwoo@...lia.com>, Ingo Molnar
 <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>, Juri Lelli
 <juri.lelli@...hat.com>, Vincent Guittot <vincent.guittot@...aro.org>,
 Dietmar Eggemann <dietmar.eggemann@....com>, Ben Segall
 <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>, Valentin Schneider
 <vschneid@...hat.com>, "sched-ext@...ts.linux.dev"
 <sched-ext@...ts.linux.dev>
Subject: Re: [RFT] sched_ext: Skip stack trace capture in NMI context

On Tue, 23 Dec 2025 04:34:00 +0000
Joel Fernandes <joelagnelf@...dia.com> wrote:

> > This does work on x86 (right?) and is useful in understanding what the
> > underlying problem is. It'd be great if there's a config flag we can test
> > but if not can we specifically exclude archs which are known to not work?  
> 
> You are right that we will miss out on architectures where this is safe.
> We should make it more specific. I am wondering if Steven Rostedt has any
> thoughts here since he is actively working on stack tracing/unwinding and
> has made similar commits in the past where he restricted stack tracing in
> an NMI context.

[ Fixes line wrap, ug it's hard to read emails that go across 300 characters! ]

Well, we do kernel stack tracing in NMI context all the time with no issue
(but I mostly work on x86).

> 
> Per my understanding, stack trace unwinding is not safe/valid to do on
> architectures where the NMI context does not have its own stack. But I

Hmm, no, I think it's fine to do it on archs where NMI doesn't have its own
stack. It works on 32bit x86, where the NMI shares the kernel stack.

Which architecture had an issue with a stack trace?

-- Steve


> could stand corrected, hence I marked this as an RFT.  It is safe to do
> on 64-bit x86, but not on 32-bit x86 and other same-stack architectures.
> 
> If we feel that this is not an issue, then that is fine with me (and
> sorry for the noise), but I just wanted to raise it anyway just in case.
> Sooner or later someone running scx on an odd architecture might
> complaint.