[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aUoCBVhHig737uKt@slm.duckdns.org>
Date: Mon, 22 Dec 2025 16:44:21 -1000
From: Tejun Heo <tj@...nel.org>
To: Joel Fernandes <joelagnelf@...dia.com>
Cc: 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>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Valentin Schneider <vschneid@...hat.com>, sched-ext@...ts.linux.dev
Subject: Re: [RFT] sched_ext: Skip stack trace capture in NMI context
Hello,
On Mon, Dec 22, 2025 at 07:50:37PM -0500, Joel Fernandes wrote:
> stack_trace_save() is not guaranteed to be NMI-safe on all
> architectures.
>
> The hardlockup detector calls into sched_ext via the following call
> chain when an NMI occurs:
>
> watchdog_overflow_callback()
> watchdog_hardlockup_check()
> scx_hardlockup()
> stack_trace_save()
>
> Skip stack trace capture when in_nmi() returns true to prevent
> potential deadlocks.
>
> Fixes: 582f700e1bdc ("sched_ext: Hook up hardlockup detector")
> Signed-off-by: Joel Fernandes <joelagnelf@...dia.com>
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?
Thanks.
--
tejun
Powered by blists - more mailing lists