From: Tejun Heo <tj@kernel.org>
To: David Vernet <void@manifault.com>
Cc: sched-ext@meta.com, kernel-team@meta.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] scx: Fix raciness in scx_ops_bypass()
Date: Fri, 25 Oct 2024 11:12:02 -1000 [thread overview]
Message-ID: <ZxwJovsaUSv8b_Zg@slm.duckdns.org> (raw)
In-Reply-To: <20241025205408.25166-1-void@manifault.com>
On Fri, Oct 25, 2024 at 03:54:08PM -0500, David Vernet wrote:
> scx_ops_bypass() can currently race on the ops enable / disable path as
> follows:
>
> 1. scx_ops_bypass(true) called on enable path, bypass depth is set to 1
> 2. An op on the init path exits, which schedules scx_ops_disable_workfn()
> 3. scx_ops_bypass(false) is called on the disable path, and bypass depth
> is decremented to 0
> 4. kthread is scheduled to execute scx_ops_disable_workfn()
> 5. scx_ops_bypass(true) called, bypass depth set to 1
> 6. scx_ops_bypass() races when iterating over CPUs
>
> While it's not safe to take any blocking locks on the bypass path, it is
> safe to take a raw spinlock which cannot be preempted. This patch therefore
> updates scx_ops_bypass() to use a raw spinlock to synchronize, and changes
> scx_ops_bypass_depth to be a regular int.
>
> Without this change, we observe the following warnings when running the
> 'exit' sched_ext selftest (sometimes requires a couple of runs):
...
> Fixes: f0e1a0643a59 ("sched_ext: Implement BPF extensible scheduler class")
> Signed-off-by: David Vernet <void@manifault.com>
Applied to sched_ext/for-6.12-fixes. Thanks!
--
tejun
prev parent reply other threads:[~2024-10-25 21:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-25 20:39 [PATCH v2] " David Vernet
2024-10-25 20:43 ` Tejun Heo
2024-10-25 20:48 ` David Vernet
2024-10-25 20:54 ` [PATCH v3] " David Vernet
2024-10-25 21:12 ` Tejun Heo [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=ZxwJovsaUSv8b_Zg@slm.duckdns.org \
--to=tj@kernel.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sched-ext@meta.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®