All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: David Vernet <void@manifault.com>,
	Andrea Righi <arighi@nvidia.com>,
	Changwoo Min <changwoo@igalia.com>
Cc: sched-ext@lists.linux.dev, Emil Tsalapatis <emil@etsalapatis.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCHSET sched_ext/for-7.3] sched_ext: NMI-safe exit handling
Date: Fri, 24 Jul 2026 14:50:14 -1000	[thread overview]
Message-ID: <20260725005019.1297049-1-tj@kernel.org> (raw)

Hello,

The exit paths weren't NMI-safe: exit claiming walked the sub-scheduler
hierarchy under scx_sched_lock and the bstr exit kfuncs formatted their
messages into a shared buffer under a raw spinlock. Kfuncs in the "any"
category are callable from tracing progs that can attach to functions
running in NMI, and many of them raise scx_error() on invalid inputs, so
an unlucky bad argument from such a prog could deadlock the machine. The
hardlockup handler had the same problem and deferred its abort to an
irq_work, which can't even run on the CPU that detected the lockup.

This series makes exit handling NMI-safe end to end:

 0001 makes exit claiming lock-free: ->aborting is asserted with a
      synchronous lockless sweep and the locked SCX_EXIT_PARENT
      propagation is deferred to an irq_work.

 0002 reverses the bstr exit sequence to claim-first so the message is
      formatted directly into the winner-owned exit_info buffer. With
      these two, scx_bpf_error() and scx_bpf_exit() are safe from any
      context including NMI.

 0003-0005 apply the newly-possible direct error reporting: NMI kicks
      abort the scheduler instead of being silently dropped, the
      hardlockup handler aborts directly from NMI making self-detected
      lockups recoverable, and scx_link_sched() reports failures inline.

 0001-sched_ext-Make-exit-claiming-lock-free.patch
 0002-sched_ext-Format-bstr-exit-messages-after-claiming-t.patch
 0003-sched_ext-Report-NMI-kicks-with-scx_error.patch
 0004-sched_ext-Abort-directly-from-the-hardlockup-handler.patch
 0005-sched_ext-Report-scx_link_sched-failures-inline.patch

Based on sched_ext/for-7.3 (3a21e34eb258).

The patches are also available in the following git branch:

 git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext.git scx-exit-nmi

diffstat follows. Thanks.

 kernel/sched/ext/ext.c      | 259 ++++++++++++++++++++++++--------------------
 kernel/sched/ext/internal.h |  10 +-
 kernel/sched/ext/sub.c      |  19 ++--
 3 files changed, 156 insertions(+), 132 deletions(-)

--
tejun

             reply	other threads:[~2026-07-25  0:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-25  0:50 Tejun Heo [this message]
2026-07-25  0:50 ` [PATCH 1/5] sched_ext: Make exit claiming lock-free Tejun Heo
2026-07-25  0:50 ` [PATCH 2/5] sched_ext: Format bstr exit messages after claiming the exit Tejun Heo
2026-07-25  0:50 ` [PATCH 3/5] sched_ext: Report NMI kicks with scx_error() Tejun Heo
2026-07-25  0:50 ` [PATCH 4/5] sched_ext: Abort directly from the hardlockup handler Tejun Heo
2026-07-25  0:50 ` [PATCH 5/5] sched_ext: Report scx_link_sched() failures inline Tejun Heo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260725005019.1297049-1-tj@kernel.org \
    --to=tj@kernel.org \
    --cc=arighi@nvidia.com \
    --cc=changwoo@igalia.com \
    --cc=emil@etsalapatis.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sched-ext@lists.linux.dev \
    --cc=void@manifault.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.