mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Tejun Heo <tj@kernel.org>
Cc: Kuba Piecuch <jpiecuch@google.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Usama Arif <usama.arif@linux.dev>
Subject: linux-next: manual merge of the sched-ext tree with the origin tree
Date: Mon, 19 Oct 2026 18:01:42 +0100	[thread overview]
Message-ID: <atZM9nFiaMvuX9kP@sirena.co.uk> (raw)

[-- Attachment #1: Type: text/plain, Size: 3451 bytes --]

Hi all,

Today's linux-next merge of the sched-ext tree got a conflict in:

  kernel/sched/ext/ext.c

between commit:

  2935062be7711 ("sched_ext: Wait for SCX_OPSS_DISPATCHING before moving tasks off DSQs")

from the origin tree and commit:

  efa7bc7d71955 ("sched_ext: Avoid relocking DSQ during remote consumption")

from the sched-ext tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc kernel/sched/ext/ext.c
index 2b6239763b230,9491e4332115f..0000000000000
--- a/kernel/sched/ext/ext.c
+++ b/kernel/sched/ext/ext.c
@@@ -2421,11 -2597,8 +2601,11 @@@ void scx_move_local_task_to_local_dsq(s
  	lockdep_assert_rq_held(dst_rq);
  
  	WARN_ON_ONCE(p->scx.holding_cpu >= 0);
 +	scx_wait_dispatching(p);
 +
 +	dst_dsq = scx_resolve_local_dsq(sch, dst_rq, p, &enq_flags);
  
- 	if (enq_flags & (SCX_ENQ_HEAD | SCX_ENQ_PREEMPT))
+ 	if (enq_flags & (SCX_ENQ_HEAD | SCX_ENQ_PREEMPT | SCX_ENQ_PREEMPT_LAZY))
  		dsq_insert_head(dst_dsq, p);
  	else
  		list_add_tail(&p->scx.dsq_list.node, &dst_dsq->list);
@@@ -2604,7 -2847,13 +2854,14 @@@ static bool unlink_dsq_and_switch_rq_lo
  
  	/* task_rq couldn't have changed if we're still the holding cpu */
  	if (likely(p->scx.holding_cpu == cpu) && !WARN_ON_ONCE(src_rq != task_rq(p))) {
 +		scx_wait_dispatching(p);
+ 		/*
+ 		 * Keep ->dsq set until we own @src_rq so that a racing dequeue
+ 		 * can find @dsq and clear holding_cpu. Once ownership is
+ 		 * confirmed, clear it under @src_rq so that deactivate_task()
+ 		 * takes the !dsq path instead of retaking @dsq->lock.
+ 		 */
+ 		p->scx.dsq = NULL;
  		return true;
  	}
  
@@@ -2651,10 -2913,21 +2921,23 @@@ static struct rq *move_task_between_dsq
  	lockdep_assert_held(&src_dsq->lock);
  	lockdep_assert_rq_held(src_rq);
  
 +	scx_wait_dispatching(p);
 +
  	if (dst_dsq->id == SCX_DSQ_LOCAL) {
  		dst_rq = container_of(dst_dsq, struct rq, scx.local_dsq);
+ 		/*
+ 		 * Unlike the rq-lock handoff paths, @src_rq has been locked
+ 		 * throughout this operation. Only active proxy state can race the
+ 		 * move here; let the enforcing check below diagnose an ordinary
+ 		 * migration-disabled task.
+ 		 */
+ 		if (src_rq != dst_rq &&
+ 		    unlikely(task_proxy_running_or_donating(p))) {
+ 			dispatch_dequeue_locked(p, src_dsq);
+ 			raw_spin_unlock(&src_dsq->lock);
+ 			scx_proxy_reject_task(sch, src_rq, p, enq_flags);
+ 			return src_rq;
+ 		}
  		if (src_rq != dst_rq &&
  		    unlikely(!task_can_run_on_remote_rq(sch, p, dst_rq, true))) {
  			dst_dsq = find_global_dsq(sch, task_cpu(p));
@@@ -4562,11 -4922,10 +4942,10 @@@ static u32 reenq_local(struct scx_sche
  		if (!local_task_should_reenq(rq, p, &reenq_flags, &reason))
  			continue;
  
 -		scx_reenq_wait_dispatching(p);
 +		scx_wait_dispatching(p);
  		scx_dispatch_dequeue(rq, p);
  
- 		if (WARN_ON_ONCE(p->scx.flags & SCX_TASK_REENQ_REASON_MASK))
- 			p->scx.flags &= ~SCX_TASK_REENQ_REASON_MASK;
+ 		WARN_ON_ONCE(p->scx.flags & SCX_TASK_REENQ_REASON_MASK);
  		p->scx.flags |= reason;
  
  		list_add_tail(&p->scx.dsq_list.node, &tasks);

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

             reply	other threads:[~2026-10-19 17:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 17:01 Mark Brown [this message]
2026-10-19 17:11 ` Tejun Heo
2026-10-19 17:01 Mark Brown
2026-10-19 17:11 ` Tejun Heo

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=atZM9nFiaMvuX9kP@sirena.co.uk \
    --to=broonie@kernel.org \
    --cc=jpiecuch@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=tj@kernel.org \
    --cc=usama.arif@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

all inboxes | Powered by JetHome®