Sched_ext development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Andrea Righi" <arighi@nvidia.com>
Cc: sched-ext@lists.linux.dev
Subject: Re: [PATCH sched_ext/for-7.2-fixes] sched_ext: Preserve rq tracking across local DSQ dispatch
Date: Tue, 07 Jul 2026 14:47:17 +0000	[thread overview]
Message-ID: <20260707144717.7876D1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260707135854.1379730-1-arighi@nvidia.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Medium] Unhandled lockdep assertion failure in scx_dsq_move() due to stale scx_locked_rq_state tracking when moving tasks across remote rqs.
--

--- Patch [1]: [PATCH sched_ext/for-7.2-fixes] sched_ext: Preserve rq tracking across local DSQ dispatch ---
commit bf8a7ba58cd085582b43e1290a1b826afac5f411
Author: Andrea Righi <arighi@nvidia.com>

sched_ext: Preserve rq tracking across local DSQ dispatch
    
This commit fixes a lockdep assertion in dispatch_to_local_dsq() that
occurs when nested operations restore a recorded rq that is no longer
locked. It clears the tracked rq before switching locks and restores
it only after reacquiring the original rq.

> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> index 691d53fe0f648..aa79dedba8aeb 100644
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c

[ ... ]

> @@ -2588,6 +2589,16 @@ static void dispatch_to_local_dsq(struct scx_sched *sch, struct rq *rq,
>  		return;
>  	}
>  
> +	/*
> +	 * This may be called from an SCX op with @rq recorded as the currently
> +	 * locked rq. Clear the tracking while switching rq locks so nested
> +	 * callbacks don't restore an rq which isn't locked anymore.
> +	 */
> +	if (tracked_rq) {
> +		WARN_ON_ONCE(tracked_rq != rq);
> +		update_locked_rq(NULL);
> +	}
> +
>  	/*
>  	 * @p is on a possibly remote @src_rq which we need to lock to move the

[Severity: Medium]
This isn't a bug introduced by this patch, but does this same lockdep
assertion failure happen in scx_dsq_move()?

Looking at scx_dsq_move() in kernel/sched/ext/ext.c, when moving a task
from a remote rq with in_balance set to true, it drops the this_rq lock:

        if (in_balance) {
                if (this_rq != src_rq) {
                        raw_spin_rq_unlock(this_rq);
                        raw_spin_rq_lock(src_rq);
                }
        } else {

Unlike the fix in dispatch_to_local_dsq() provided here, scx_dsq_move()
does not clear the tracked scx_locked_rq_state before dropping the lock.

If move_task_between_dsqs() then triggers nested callbacks like
SCX_CALL_OP_TASK(sch, dequeue, ...), won't it save the stale this_rq state,
and then trigger the same lockdep assertion in update_locked_rq() when
it tries to restore it?

> @@ -2640,6 +2651,8 @@ static void dispatch_to_local_dsq(struct scx_sched *sch, struct rq *rq,
>  		raw_spin_rq_unlock(locked_rq);
>  		raw_spin_rq_lock(rq);
>  	}
> +	if (tracked_rq)
> +		update_locked_rq(tracked_rq);
>  }
>  
>  /**

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260707135854.1379730-1-arighi@nvidia.com?part=1

      reply	other threads:[~2026-07-07 14:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-07 13:58 [PATCH sched_ext/for-7.2-fixes] sched_ext: Preserve rq tracking across local DSQ dispatch Andrea Righi
2026-07-07 14:47 ` sashiko-bot [this message]

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=20260707144717.7876D1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=arighi@nvidia.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sched-ext@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox