Re: [PATCH v3 1/2] sched_ext: Don't run ops.dequeue() with a DSQ lock held

[Tejun Heo <tj@kernel.org>]

Hello, Qiurong.

On Wed, Sep 16, 2026 at 03:07:52PM +0800, Qiurong Fang wrote:
> ops.dequeue() can only call the "any" kfuncs and none of them can lock a
> builtin DSQ, so the global and bypass paths can't deadlock; however,
> all DSQ locks share one lockdep class, so iterating any user DSQ from
> ops.dequeue() there trips the recursion check.

"there" has no referent. "on those paths" or similar.

> +		 * The custody transfer happens under @dsq->lock so that
> +		 * later consumers see the flag clear; the callback runs
> +		 * unlocked - it must not run with a DSQ lock held.

The callback isn't unlocked. The rq lock is held on every path. Only
@dsq->lock is dropped. Say that it runs after @dsq->lock is dropped because
it may lock a DSQ itself.

> -	/* @p is on @dst_rq, an rq-owned @src_dsq is covered by the rq lock */
> -	if (!dsq_is_rq_owned(src_dsq))
> -		lockdep_assert_held(&src_dsq->lock);

This leaves @src_dsq unused in scx_move_local_task_to_local_dsq(). Please
drop the parameter from the function and its callers, including the three
in sub.c.

Thanks.

--
tejun