From: Andrea Righi <arighi@nvidia.com>
To: Jake Hillion <jake@hillion.co.uk>
Cc: Tejun Heo <tj@kernel.org>,
Christian Loehle <christian.loehle@arm.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: Tue, 12 Aug 2025 15:31:54 +0200 [thread overview]
Message-ID: <aJtCSjsCEtN1csjg@gpd4> (raw)
In-Reply-To: <y23etey3foin5nrxgj6e4g373b3ap6oxqa5rrvuvwyus3umw5s@bgh3d6uuga5t>
On Mon, Aug 11, 2025 at 03:35:05PM +0100, Jake Hillion wrote:
> On Sun, Aug 10, 2025 at 12:52:53PM +0200, Andrea Righi 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.
>
> I ran some testing on the sched_ext for-next branch, and scx_cosmos is
> breaking in cosmos_init including the latest changes. I believe it kicks
> off a timer in init, which indirectly calls
> `scx_bpf_cpu_rq(cpu)->curr->flags & PF_IDLE`. This should be NULL
> checked, but old binaries breaking is pretty inconvenient for new users.
>
> As Andrea says, this is the already merged patch triggering this.
We should provide a compat helper in common.bpf.h and fix the schedulers to
use this helper. Something like the following (untested):
static inline struct task_struct *
__COMPAT_scx_bpf_task_acquire_remote_curr(s32 cpu)
{
struct rq *rq;
if (bpf_ksym_exists(scx_bpf_task_acquire_remote_curr)
return scx_bpf_task_acquire_remote_curr(cpu);
rq = scx_bpf_cpu_rq(cpu);
return rq ? rq->curr : NULL;
}
Then we can drop this after a couple of kernel releases (like in v6.20).
-Andrea
next prev parent reply other threads:[~2025-08-12 13:32 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
2025-08-11 14:35 ` Jake Hillion
2025-08-11 16:51 ` Tejun Heo
2025-08-12 13:31 ` Andrea Righi [this message]
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=aJtCSjsCEtN1csjg@gpd4 \
--to=arighi@nvidia.com \
--cc=changwoo@igalia.com \
--cc=christian.loehle@arm.com \
--cc=hodgesd@meta.com \
--cc=jake@hillion.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=sched-ext@lists.linux.dev \
--cc=tj@kernel.org \
--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.