From: Tejun Heo <tj@kernel.org>
To: Christian Loehle <christian.loehle@arm.com>
Cc: Andrea Righi <arighi@nvidia.com>,
void@manifault.com, linux-kernel@vger.kernel.org,
sched-ext@lists.linux.dev, changwoo@igalia.com, hodgesd@meta.com,
mingo@redhat.com, peterz@infradead.org
Subject: Re: [PATCH v3 3/3] sched_ext: Guarantee rq lock on scx_bpf_cpu_rq()
Date: Mon, 11 Aug 2025 06:52:53 -1000 [thread overview]
Message-ID: <aJof5QVDR7x-TePI@slm.duckdns.org> (raw)
In-Reply-To: <cc68722b-75f8-4de8-bf83-0fc1518ad60c@arm.com>
Hello,
On Sun, Aug 10, 2025 at 11:18:52PM +0100, Christian Loehle wrote:
...
> > Yeah, this is not nice, but they would be still broken though, in PATCH 1/3
> > we force schedulers to check for NULL and, if they don't, the verifier
> > won't be happy, so this already breaks existing binaries.
> >
> > Even if a scheduler performs the NULL check, this change might still cause
> > incorrect behaviors, which can be worse than triggering an error.
I'll revert that change. We shouldn't be introducing breaking changes
without grace period.
> > How about we introduce scx_bpf_locked_cpu_rq() and we still trigger an
> > error in scx_bpf_cpu_rq(), mentioning about the new locked kfunc and
> > scx_bpf_task_acquire_remote_curr()?
>
> If we still trigger an error in scx_bpf_cpu_rq() what's the difference
> between scx_bpf_cpu_rq() and scx_bpf_cpu_rq_locked() then?
> Just the error message?
Let's add a warning to scx_bpf_cpu_rq() pointing to scx_bpf_cpu_rq_locked(),
update the schedulers, and drop scx_bpf_cpu_rq() in a couple releases.
Thanks.
--
tejun
next prev parent reply other threads:[~2025-08-11 16:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-05 11:10 [PATCH v3 0/3] sched_ext: Harden scx_bpf_cpu_rq() Christian Loehle
2025-08-05 11:10 ` [PATCH v3 1/3] sched_ext: Mark scx_bpf_cpu_rq as NULL returnable Christian Loehle
2025-08-05 11:10 ` [PATCH v3 2/3] sched_ext: Provide scx_bpf_task_acquire_remote_curr() Christian Loehle
2025-08-09 19:01 ` Tejun Heo
2025-08-11 17:08 ` Tejun Heo
2025-08-05 11:10 ` [PATCH v3 3/3] sched_ext: Guarantee rq lock on scx_bpf_cpu_rq() Christian Loehle
2025-08-09 19:03 ` Tejun Heo
2025-08-10 10:52 ` Andrea Righi
2025-08-10 22:18 ` Christian Loehle
2025-08-11 16:52 ` Tejun Heo [this message]
2025-08-11 14:35 ` Jake Hillion
2025-08-11 16:51 ` Tejun Heo
2025-08-12 13:31 ` Andrea Righi
2025-08-05 14:33 ` [PATCH v3 0/3] sched_ext: Harden scx_bpf_cpu_rq() Andrea Righi
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=aJof5QVDR7x-TePI@slm.duckdns.org \
--to=tj@kernel.org \
--cc=arighi@nvidia.com \
--cc=changwoo@igalia.com \
--cc=christian.loehle@arm.com \
--cc=hodgesd@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.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.