From: sashiko-bot@kernel.org
To: Zqiang <qiang.zhang@linux.dev>
Cc: sched-ext@lists.linux.dev
Subject: Re: [PATCH] sched_ext: Use IRQ_WORK_INIT_HARD() to initialize sch->disable_irq_work
Date: Fri, 08 May 2026 20:47:33 +0000 [thread overview]
Message-ID: <20260508204734.12EC6C2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260508115045.23739-1-qiang.zhang@linux.dev>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch forces scx_disable_irq_workfn to run in hardirq context, causing unbounded execution time with interrupts disabled, which severely breaks PREEMPT_RT latency guarantees.
--
commit 3f0e90ad5f7a3132810aa08d6137cba68235020c
Author: Zqiang <qiang.zhang@linux.dev>
sched_ext: Use IRQ_WORK_INIT_HARD() to initialize sch->disable_irq_work
This commit changes the initialization of the disable_irq_work in sched_ext
to use IRQ_WORK_INIT_HARD(). The intention is to force
scx_disable_irq_workfn() to run in hardirq context rather than a threaded
kthread on PREEMPT_RT, so that scx_dump_state() captures the expected
comm and pid.
> diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
> index 345aa11b84b28..c6b6038a97010 100644
> --- a/kernel/sched/ext.c
> +++ b/kernel/sched/ext.c
[ ... ]
> @@ -6559,7 +6559,7 @@ static struct scx_sched *scx_alloc_and_add_sched(struct sched_ext_ops *ops,
>
> sch->slice_dfl = SCX_SLICE_DFL;
> atomic_set(&sch->exit_kind, SCX_EXIT_NONE);
> - init_irq_work(&sch->disable_irq_work, scx_disable_irq_workfn);
> + sch->disable_irq_work = IRQ_WORK_INIT_HARD(scx_disable_irq_workfn);
Will executing this in hardirq context cause severe latency spikes or hard
lockups on PREEMPT_RT?
scx_disable_irq_workfn() calls scx_dump_state(), which performs a heavy
workload. It iterates over all possible CPUs, takes their raw_spinlock_t
runqueue locks, formats sequence buffers, saves stack traces, and executes
BPF dump callbacks.
Performing this work with interrupts entirely disabled can break PREEMPT_RT
latency guarantees.
Instead of moving the entire dump to hardirq context, could the original
task's comm and pid be captured and stored in scx_exit_info during
scx_vexit()?
This would allow the heavy dump workload to remain safely deferred to the
threaded kthread execution.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260508115045.23739-1-qiang.zhang@linux.dev?part=1
prev parent reply other threads:[~2026-05-08 20:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-08 11:50 [PATCH] sched_ext: Use IRQ_WORK_INIT_HARD() to initialize sch->disable_irq_work Zqiang
2026-05-08 15:14 ` Tejun Heo
2026-05-08 20:47 ` sashiko-bot [this message]
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=20260508204734.12EC6C2BCB0@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=qiang.zhang@linux.dev \
--cc=sashiko@lists.linux.dev \
--cc=sched-ext@lists.linux.dev \
/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.