linux-kernel - Re: [PATCH v3 3/3] sched_ext: Allow scx_bpf_reenqueue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aTrvRpr8yblKXlP7@slm.duckdns.org>
Date: Thu, 11 Dec 2025 06:20:22 -1000
From: Tejun Heo <tj@...nel.org>
To: Kuba Piecuch <jpiecuch@...gle.com>
Cc: David Vernet <void@...ifault.com>,
	Andrea Righi <andrea.righi@...ux.dev>,
	Changwoo Min <changwoo@...lia.com>, linux-kernel@...r.kernel.org,
	sched-ext@...ts.linux.dev, Peter Zijlstra <peterz@...radead.org>,
	Wen-Fang Liu <liuwenfang@...or.com>
Subject: Re: [PATCH v3 3/3] sched_ext: Allow scx_bpf_reenqueue_local() to be
 called from anywhere

On Thu, Dec 11, 2025 at 06:17:03AM -1000, Tejun Heo wrote:
> Hello, Kuba.
> 
> On Thu, Dec 11, 2025 at 02:24:04PM +0000, Kuba Piecuch wrote:
> > Since we're doing a direct dispatch, the user scheduler task will be
> > inserted into the dispatch queue in enable_task_scx(), without dropping the rq
> > lock between example_enqueue() and the insertion, which means reenq_local()
> > will run afterwards (since it's deferred using irq_work), removing all tasks
> > from the DSQ, including the userspace scheduler.
> > 
> > A similar problem arises even if we don't do direct dispatch and drop the rq
> > lock after example_enqueue(): since dispatching and reenq_local() are deferred
> > using different irq_work entries, and irq_work_run() processes entries from
> > newest to oldest, dispatching will be handled before reenq_local(), yielding
> > the same result.
> 
> Oh yeah, the asynchronity can become pretty confusing.
> 
> > The user may be unaware of this behavior (it's not mentioned anywhere) and
> > expect the reenqueue to happen before dispatching the new task.
> > 
> > I think at the very least we should make users aware of this in the comment
> > for scx_bpf_reenqueue_local___v2().
> 
> Documentation is always helpful but I wonder whether this can be improved by
> the reenqueue function capturing the dsq seq number and re-enqueueing only
> the ones that were enqueued before the reenqueue was called.

That doesn't fix the ordering problem in the other direction, but the
reordering in the other direction seems inherently less useful at least.
Maybe this can also be solved with seq - ie. make enqueue record the current
seq, mark the DSQ with the latest reenqueue seq and at enqueue commit time
if the captured seq is alreaddy reenqueued, trigger reenqueue.

Thanks.

-- 
tejun