All of lore.kernel.org
 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 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.