[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aJoffsJn0tbJrwcs@slm.duckdns.org>
Date: Mon, 11 Aug 2025 06:51:10 -1000
From: Tejun Heo <tj@...nel.org>
To: Jake Hillion <jake@...lion.co.uk>
Cc: Andrea Righi <arighi@...dia.com>,
Christian Loehle <christian.loehle@....com>, void@...ifault.com,
linux-kernel@...r.kernel.org, sched-ext@...ts.linux.dev,
changwoo@...lia.com, hodgesd@...a.com, mingo@...hat.com,
peterz@...radead.org
Subject: Re: [PATCH v3 3/3] sched_ext: Guarantee rq lock on scx_bpf_cpu_rq()
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.
Lemme revert that. I don't think we should introduce breaking changes
without grace period.
Thanks.
--
tejun
Powered by blists - more mailing lists