[PATCH RFC v2] sched/proxy: Defer donor commit until proxy resolution

[PATCH RFC v2] sched/proxy: Defer donor commit until proxy resolution

[Xukai Wang]

Hi,

This RFC tries to decouple proxy candidate selection from donor commit in the
scheduler core.

Currently pick_next_task() does not only select a task. It also commits the
selected task into the scheduling class state through put_prev_set_next_task().
With proxy execution enabled, the selected task may be a blocked donor,
and __schedule() then calls find_proxy_task() to resolve the proxy chain and
find the task that should actually run.

If find_proxy_task() returns NULL, __schedule() goes back to pick_again.
However, the picked donor has already been committed into the class current state.
This means the scheduler may first set_next() a blocked donor and then immediately
abandon that choice when proxy resolution fails.

This patch changes the model so that pick_next_task() only returns a candidate.
The actual class commit is moved to __schedule(), after proxy resolution.

I am keeping this as RFC and including John, as discussed in the v1 thread,
to check whether find_proxy_task() or the wider proxy series relies on rq->donor
being updated to the picked donor before proxy-chain resolution.

Signed-off-by: Xukai Wang <kingxukai@zohomail.com>
---
Changes in v2:
- Move the final put_prev_set_next_task()/rq_set_donor() after the
  proxy/non-proxy branches.
- Move zap_balance_callbacks() from the NULL/idle proxy-resolution
  paths into proxy_resched_idle(), next to the idle commit.
- Link to v1: https://patch.msgid.link/20260707-sched-proxy-v1-0-5928bf6dedf0@zohomail.com

---
Xukai Wang (1):
      sched/proxy: Defer donor commit until after proxy resolution

 kernel/sched/core.c | 90 +++++++++++++++++++++++++++++------------------------
 1 file changed, 49 insertions(+), 41 deletions(-)
---
base-commit: 19b7bdc3a1550ab2550427c33395bec7caeaf72d
change-id: 20260707-sched-proxy-4404b6e97ad9

Best regards,
--  
Xukai Wang <kingxukai@zohomail.com>

[PATCH RFC v2] sched/proxy: Defer donor commit until after proxy resolution

[Xukai Wang]

pick_next_task() currently commits the selected task into the scheduling
class state before proxy execution has resolved whether that task should
really become the committed donor.

With proxy execution enabled, the task returned by pick_next_task() may
be blocked. __schedule() then calls find_proxy_task() to resolve the
proxy chain. If find_proxy_task() returns NULL, __schedule() retries
through pick_again, but the picked donor has already gone through
put_prev_set_next_task(). In that case the class current state was
speculatively switched to a donor which is not the final scheduling
decision.

Make pick_next_task() return only the selected candidate task. Move the
put_prev_set_next_task() call into __schedule(), next to rq_set_donor(),
so the scheduling class commit happens after proxy-chain resolution.

For proxy execution, keep the picked donor separate from the actual task
to run:

  donor = task selected by pick_next_task()
  next  = task returned by find_proxy_task(), possibly the proxy owner

Only commit the donor after proxy-chain resolution succeeds:

  put_prev_set_next_task(rq, rq->donor, donor);
  rq_set_donor(rq, donor);

If find_proxy_task() returns NULL, the candidate donor has not been
committed and __schedule() can retry without first undoing a speculative
set_next() on that donor.

A proxy candidate is not necessarily the committed rq->donor anymore.
Update proxy_deactivate() accordingly. If the task being blocked is
still the committed donor, proxy_resched_idle() is needed to drop
rq/class current references before block_task() clears ->on_rq. If
it is only an uncommitted proxy candidate, it is still queued and can
be blocked directly.

proxy_migrate_task() still switches the rq to idle before dropping the
rq lock. Migrating a task found in the proxy chain abandons the current
proxy pick attempt, and switching the committed donor to idle leaves
rq->donor and the class current state in a defined state while the chain
is modified and the task is attached elsewhere.

Move zap_balance_callbacks() into proxy_resched_idle(), next to the idle
commit. The outer NULL/idle proxy-resolution paths no longer zap
unconditionally: if no put/set was done, no callbacks should have been
generated there; if the path went through proxy_resched_idle(),
callbacks are cleared at the point that performed the idle commit.

Signed-off-by: Xukai Wang <kingxukai@zohomail.com>
---
 kernel/sched/core.c | 90 +++++++++++++++++++++++++++++------------------------
 1 file changed, 49 insertions(+), 41 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2e7cde033a31..f09f3f2bea13 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6146,7 +6146,6 @@ __pick_next_task(struct rq *rq, struct rq_flags *rf)
 		if (!p)
 			p = pick_task_idle(rq, rf);
 
-		put_prev_set_next_task(rq, rq->donor, p);
 		return p;
 	}
 
@@ -6157,10 +6156,8 @@ __pick_next_task(struct rq *rq, struct rq_flags *rf)
 		p = class->pick_task(rq, rf);
 		if (unlikely(p == RETRY_TASK))
 			goto restart;
-		if (p) {
-			put_prev_set_next_task(rq, rq->donor, p);
+		if (p)
 			return p;
-		}
 	}
 
 	BUG(); /* The idle class should always have a runnable task. */
@@ -6257,7 +6254,7 @@ pick_next_task(struct rq *rq, struct rq_flags *rf)
 		rq->dl_server = rq->core_dl_server;
 		rq->core_pick = NULL;
 		rq->core_dl_server = NULL;
-		goto out_set_next;
+		goto out_return_next;
 	}
 
 	prev_balance(rq, rf);
@@ -6311,7 +6308,7 @@ pick_next_task(struct rq *rq, struct rq_flags *rf)
 			 */
 			WARN_ON_ONCE(fi_before);
 			task_vruntime_update(rq, next, false);
-			goto out_set_next;
+			goto out_return_next;
 		}
 	}
 
@@ -6441,8 +6438,7 @@ pick_next_task(struct rq *rq, struct rq_flags *rf)
 		resched_curr(rq_i);
 	}
 
-out_set_next:
-	put_prev_set_next_task(rq, rq->donor, next);
+out_return_next:
 	if (rq->core->core_forceidle_count && next == rq->idle)
 		queue_core_balance(rq);
 
@@ -6745,6 +6741,14 @@ static inline struct task_struct *proxy_resched_idle(struct rq *rq)
 	rq->next_class = &idle_sched_class;
 	rq_set_donor(rq, rq->idle);
 	set_tsk_need_resched(rq->idle);
+
+	/*
+	 * This helper performs a real idle commit. Some callers return to
+	 * __schedule() without dropping rq->lock, so clear callbacks
+	 * generated by the idle commit here. Paths that later drop
+	 * rq->lock may zap again.
+	 */
+	zap_balance_callbacks(rq);
 	return rq->idle;
 }
 
@@ -6755,15 +6759,23 @@ static void proxy_deactivate(struct rq *rq, struct task_struct *donor)
 	WARN_ON_ONCE(state == TASK_RUNNING);
 	WARN_ON_ONCE(donor->blocked_on);
 	/*
-	 * Because we got donor from pick_next_task(), it is *crucial*
-	 * that we call proxy_resched_idle() before we deactivate it.
-	 * As once we deactivate donor, donor->on_rq is set to zero,
-	 * which allows ttwu() to immediately try to wake the task on
-	 * another rq. So we cannot use *any* references to donor
-	 * after that point. So things like cfs_rq->curr or rq->donor
-	 * need to be changed from next *before* we deactivate.
+	 * A proxy candidate is not necessarily the committed rq->donor.
+	 * pick_next_task() only selected it; the class current state is
+	 * updated later, after proxy-chain resolution.
+	 *
+	 * If @donor is still the committed donor, the rq and the scheduling
+	 * class may hold current references to it, such as rq->donor or
+	 * cfs_rq->curr/h_curr. Drop those references before block_task(),
+	 * because block_task() clears donor->on_rq and a concurrent wakeup
+	 * may then move the task elsewhere.
+	 *
+	 * If @donor is only an uncommitted proxy candidate, it is still a
+	 * queued task, not the class current task, so it can be blocked
+	 * directly.
 	 */
-	proxy_resched_idle(rq);
+	if (donor == rq->donor)
+		proxy_resched_idle(rq);
+
 	block_task(rq, donor, state);
 }
 
@@ -6816,15 +6828,17 @@ static void proxy_migrate_task(struct rq *rq, struct rq_flags *rf,
 	lockdep_assert_rq_held(rq);
 	WARN_ON(p == rq->curr);
 	/*
-	 * Since we are migrating a blocked donor, it could be rq->donor,
-	 * and we want to make sure there aren't any references from this
-	 * rq to it before we drop the lock. This avoids another cpu
-	 * jumping in and grabbing the rq lock and referencing rq->donor
-	 * or cfs_rq->curr, etc after we have migrated it to another cpu,
-	 * and before we pick_again in __schedule.
+	 * Migrating a task found in the proxy chain abandons the current proxy
+	 * pick attempt and drops this rq's lock.
 	 *
-	 * So call proxy_resched_idle() to drop the rq->donor references
-	 * before we release the lock.
+	 * The picked proxy candidate has not necessarily been committed, so
+	 * @p is not necessarily rq->donor. Switch the currently committed
+	 * donor to idle before dropping the lock, leaving rq->donor and the
+	 * class current state in a well-defined state while the chain is
+	 * modified and @p is attached elsewhere.
+	 *
+	 * If @p is rq->donor, this also drops the direct rq/class-current
+	 * references to @p before it leaves this rq.
 	 */
 	proxy_resched_idle(rq);
 
@@ -7057,7 +7071,7 @@ find_proxy_task(struct rq *rq, struct task_struct *donor, struct rq_flags *rf)
  */
 static void __sched notrace __schedule(int sched_mode)
 {
-	struct task_struct *prev, *next;
+	struct task_struct *prev, *next, *donor;
 	/*
 	 * On PREEMPT_RT kernel, SM_RTLOCK_WAIT is noted
 	 * as a preemption by schedule_debug() and RCU.
@@ -7145,24 +7159,18 @@ static void __sched notrace __schedule(int sched_mode)
 	assert_balance_callbacks_empty(rq);
 	next = pick_next_task(rq, &rf);
 	rq->next_class = next->sched_class;
+	donor = next;
 	if (sched_proxy_exec()) {
-		struct task_struct *prev_donor = rq->donor;
-
-		rq_set_donor(rq, next);
-		next->blocked_donor = NULL;
-		if (unlikely(next->is_blocked)) {
-			next = find_proxy_task(rq, next, &rf);
-			if (!next) {
-				zap_balance_callbacks(rq);
+		donor->blocked_donor = NULL;
+		if (unlikely(donor->is_blocked)) {
+			next = find_proxy_task(rq, donor, &rf);
+			if (!next)
 				goto pick_again;
-			}
-			if (next == rq->idle) {
-				zap_balance_callbacks(rq);
+			if (next == rq->idle)
 				goto keep_resched;
-			}
 		}
-		if (rq->donor == prev_donor && prev != next) {
-			struct task_struct *donor = rq->donor;
+
+		if (donor == rq->donor && prev != next) {
 			/*
 			 * When transitioning like:
 			 *
@@ -7178,9 +7186,9 @@ static void __sched notrace __schedule(int sched_mode)
 			donor->sched_class->put_prev_task(rq, donor, donor);
 			donor->sched_class->set_next_task(rq, donor, true);
 		}
-	} else {
-		rq_set_donor(rq, next);
 	}
+	put_prev_set_next_task(rq, rq->donor, donor);
+	rq_set_donor(rq, donor);
 
 picked:
 	clear_tsk_need_resched(prev);

-- 
2.34.1

Re: [PATCH RFC v2] sched/proxy: Defer donor commit until after proxy resolution

[Xukai Wang]

Hi Prateek, John,

A follow-up on this RFC v2.

On 2026/7/13 14:21, Xukai Wang wrote:
> pick_next_task() currently commits the selected task into the scheduling
> class state before proxy execution has resolved whether that task should
> really become the committed donor.
>
> With proxy execution enabled, the task returned by pick_next_task() may
> be blocked. __schedule() then calls find_proxy_task() to resolve the
> proxy chain. If find_proxy_task() returns NULL, __schedule() retries
> through pick_again, but the picked donor has already gone through
> put_prev_set_next_task(). In that case the class current state was
> speculatively switched to a donor which is not the final scheduling
> decision.
>
> Make pick_next_task() return only the selected candidate task. Move the
> put_prev_set_next_task() call into __schedule(), next to rq_set_donor(),
> so the scheduling class commit happens after proxy-chain resolution.
>
> For proxy execution, keep the picked donor separate from the actual task
> to run:
>
>   donor = task selected by pick_next_task()
>   next  = task returned by find_proxy_task(), possibly the proxy owner
>
> Only commit the donor after proxy-chain resolution succeeds:
>
>   put_prev_set_next_task(rq, rq->donor, donor);
>   rq_set_donor(rq, donor);
>
> If find_proxy_task() returns NULL, the candidate donor has not been
> committed and __schedule() can retry without first undoing a speculative
> set_next() on that donor.
>
> A proxy candidate is not necessarily the committed rq->donor anymore.
> Update proxy_deactivate() accordingly. If the task being blocked is
> still the committed donor, proxy_resched_idle() is needed to drop
> rq/class current references before block_task() clears ->on_rq. If
> it is only an uncommitted proxy candidate, it is still queued and can
> be blocked directly.
>
> proxy_migrate_task() still switches the rq to idle before dropping the
> rq lock. Migrating a task found in the proxy chain abandons the current
> proxy pick attempt, and switching the committed donor to idle leaves
> rq->donor and the class current state in a defined state while the chain
> is modified and the task is attached elsewhere.
>
> Move zap_balance_callbacks() into proxy_resched_idle(), next to the idle
> commit. The outer NULL/idle proxy-resolution paths no longer zap
> unconditionally: if no put/set was done, no callbacks should have been
> generated there; if the path went through proxy_resched_idle(),
> callbacks are cleared at the point that performed the idle commit.

While revisiting the patch, I noticed one detail that needs to be handled

when deferring put_prev_set_next_task(): rq->dl_server.


On the v2 base, before this change, put_prev_set_next_task() is called

inside pick_next_task(), so rq->dl_server has already been consumed and

cleared by the time __schedule() calls find_proxy_task(). In other words,

find_proxy_task() is entered with rq->dl_server == NULL.


With the commit deferred by this RFC, rq->dl_server can still contain the

state from the candidate pick when find_proxy_task() is called. I think

the original entry state can be preserved by saving and clearing it

around proxy resolution, roughly:


|next = pick_next_task(rq, &rf);|

|donor = next;|

|rq->next_class = donor->sched_class;|

||
|if (sched_proxy_exec()) {|
|  donor->blocked_donor = NULL;|
||
|  if (unlikely(donor->is_blocked)) {|
|    struct sched_dl_entity *donor_dl_server = rq->dl_server;|
|    rq->dl_server = NULL;|
||
|    next = find_proxy_task(rq, donor, &rf);|
|    if (!next)|
|      goto pick_again;|
|    if (next == rq->idle)|
|      goto keep_resched;|
||
|    rq->dl_server = donor_dl_server;|
|  }|
|...|
|}|
||
|put_prev_set_next_task(rq, rq->donor, donor);|
|rq_set_donor(rq, donor);|

|
|

This keeps rq->dl_server == NULL on entry to find_proxy_task(), as it was

before this RFC, while restoring it for the final donor commit when proxy

resolution succeeds.


Before sending a v3 with this addressed, I wanted to check whether the

overall direction still looks reasonable, particularly whether

find_proxy_task() has any dependency on rq->donor already being updated

to the picked donor before proxy resolution.

-- 
Best regards,
Xukai

Re: [PATCH RFC v2] sched/proxy: Defer donor commit until after proxy resolution

[John Stultz]

On Sun, Jul 12, 2026 at 11:22 PM Xukai Wang <kingxukai@zohomail.com> wrote:
>
> pick_next_task() currently commits the selected task into the scheduling
> class state before proxy execution has resolved whether that task should
> really become the committed donor.
>
> With proxy execution enabled, the task returned by pick_next_task() may
> be blocked. __schedule() then calls find_proxy_task() to resolve the
> proxy chain. If find_proxy_task() returns NULL, __schedule() retries
> through pick_again, but the picked donor has already gone through
> put_prev_set_next_task(). In that case the class current state was
> speculatively switched to a donor which is not the final scheduling
> decision.
>
> Make pick_next_task() return only the selected candidate task. Move the
> put_prev_set_next_task() call into __schedule(), next to rq_set_donor(),
> so the scheduling class commit happens after proxy-chain resolution.

Hey Xukai!
  Thanks for sending this out, and my apologies for being a little
slow to respond.

It might help if your commit message focused in to explain a bit more
about *why* these changes are useful.

ie: Why is the call to set_next_task on the donor problematic if we
pick a different task to run?

Is this just trying to optimize out the potentially repeated
put_prev/set_next calls needed if we have to pick_again repeatedly? Or
are there other benefits?

What is the impact of this change? Is it measurable?

These would be good things to answer at the top of the commit message.

thanks
-john

Re: [PATCH RFC v2] sched/proxy: Defer donor commit until after proxy resolution

[Xukai Wang]

On 2026/8/12 04:41, John Stultz wrote:
> On Sun, Jul 12, 2026 at 11:22 PM Xukai Wang <kingxukai@zohomail.com> wrote:
>> pick_next_task() currently commits the selected task into the scheduling
>> class state before proxy execution has resolved whether that task should
>> really become the committed donor.
>>
>> With proxy execution enabled, the task returned by pick_next_task() may
>> be blocked. __schedule() then calls find_proxy_task() to resolve the
>> proxy chain. If find_proxy_task() returns NULL, __schedule() retries
>> through pick_again, but the picked donor has already gone through
>> put_prev_set_next_task(). In that case the class current state was
>> speculatively switched to a donor which is not the final scheduling
>> decision.
>>
>> Make pick_next_task() return only the selected candidate task. Move the
>> put_prev_set_next_task() call into __schedule(), next to rq_set_donor(),
>> so the scheduling class commit happens after proxy-chain resolution.
> Hey Xukai!
>   Thanks for sending this out, and my apologies for being a little
> slow to respond.
>
> It might help if your commit message focused in to explain a bit more
> about *why* these changes are useful.
>
> ie: Why is the call to set_next_task on the donor problematic if we
> pick a different task to run?
>
> Is this just trying to optimize out the potentially repeated
> put_prev/set_next calls needed if we have to pick_again repeatedly? Or
> are there other benefits?
>
> What is the impact of this change? Is it measurable?
>
> These would be good things to answer at the top of the commit message.
>
> thanks
> -john
Hi John,
Thanks for taking a look. That's a good point, and I should have made
the motivation clearer in the commit message.

The main issue I was trying to address is that pick_next_task() currently
couples picking a task with committing that pick through
put_prev_set_next_task().

That works naturally when the task returned by pick_next_task() is the
final scheduling decision. With proxy execution, however, the picked
task may be a blocked donor and still needs to go through
find_proxy_task(). If proxy resolution returns NULL, __schedule() goes
back to pick_again, and the next pick may be a different task. In that
case, the put_prev_task()/set_next_task() work done for the previous pick
is followed by another put_prev_set_next_task() for the new pick, even
though the previous pick was ultimately abandoned.

The change is therefore mainly intended to avoid that unnecessary
put_prev/set_next work by separating candidate selection from the point
where the donor is actually committed.

I did some temporary instrumentation to measure how frequently this
happens and posted the results in the v1 cover letter and follow-up
discussion, but I should have carried them into the v2 commit message as
well. Sorry about that.

For example, in one 60s proxy-mutex stress run:

spec_commit_blocked 5407
spec_commit_then_null 3224
spec_commit_then_idle 1660
spec_commit_then_success 523

For the 3224 NULL cases, the following retry picked:
null_retry_same_donor 0
null_retry_diff_donor 2258
null_retry_to_idle 966
The temporary counters mean:
- spec_commit_blocked:
pick_next_task() selected a blocked donor, and in
the baseline code that donor had already gone through
put_prev_set_next_task() before proxy-chain resolution.

- spec_commit_then_null:
the blocked donor had already been committed, but
find_proxy_task() returned NULL and __schedule() retried.

- spec_commit_then_idle:
the blocked donor had already been committed, but
find_proxy_task() returned rq->idle.

- spec_commit_then_success:
the blocked donor had already been committed,
and find_proxy_task() successfully found a task to run.

- null_retry_same_donor:
after find_proxy_task() returned NULL, the next pick selected the same
donor again.

- null_retry_diff_donor:
after find_proxy_task() returned NULL, the next pick selected a
different non-idle donor.

- null_retry_to_idle:
after find_proxy_task() returned NULL, the next pick selected idle.

So in that run, none of the NULL retries selected the same donor again:
2258 switched to a different non-idle donor and 966 switched to idle.
Those are cases where the put_prev/set_next work done for the previous
pick is followed by another scheduling transition after proxy resolution
fails.

At this point I only have the frequency measurements above, not a
measurement of how much performance is gained by eliminating those
calls. Prateek also mentioned in the v1 discussion that he would look at
the performance side using schedstats.

I'll put this motivation and the frequency results near the top of the
v3 commit message so the purpose and the scope of the measurements are
clear.

-- 
Thanks,
Xukai

Re: [PATCH RFC v2] sched/proxy: Defer donor commit until after proxy resolution

[kernel test robot]

Hi Xukai,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build warnings:

[auto build test WARNING on tip/sched/core]
[also build test WARNING on tip/master peterz-queue/sched/core linus/master v7.2-rc7]
[cannot apply to tip/auto-latest next-20260814]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Xukai-Wang/sched-proxy-Defer-donor-commit-until-after-proxy-resolution/20260814-163837
base:   tip/sched/core
patch link:    https://lore.kernel.org/r/20260713-sched-proxy-v2-1-729170082633%40zohomail.com
patch subject: [PATCH RFC v2] sched/proxy: Defer donor commit until after proxy resolution
config: alpha-defconfig (https://download.01.org/0day-ci/archive/20260816/202608161357.Jthx08U8-lkp@intel.com/config)
compiler: alpha-linux-gcc (GCC) 16.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260816/202608161357.Jthx08U8-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202608161357.Jthx08U8-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> kernel/sched/core.c:5103:13: warning: 'zap_balance_callbacks' defined but not used [-Wunused-function]
    5103 | static void zap_balance_callbacks(struct rq *rq)
         |             ^~~~~~~~~~~~~~~~~~~~~


vim +/zap_balance_callbacks +5103 kernel/sched/core.c

31cb1bc0dc9488 Rodrigo Siqueira 2017-12-15  5092  
48fda62de67a1e John Stultz      2026-03-24  5093  /*
48fda62de67a1e John Stultz      2026-03-24  5094   * Only called from __schedule context
48fda62de67a1e John Stultz      2026-03-24  5095   *
48fda62de67a1e John Stultz      2026-03-24  5096   * There are some cases where we are going to re-do the action
48fda62de67a1e John Stultz      2026-03-24  5097   * that added the balance callbacks. We may not be in a state
48fda62de67a1e John Stultz      2026-03-24  5098   * where we can run them, so just zap them so they can be
48fda62de67a1e John Stultz      2026-03-24  5099   * properly re-added on the next time around. This is similar
48fda62de67a1e John Stultz      2026-03-24  5100   * handling to running the callbacks, except we just don't call
48fda62de67a1e John Stultz      2026-03-24  5101   * them.
48fda62de67a1e John Stultz      2026-03-24  5102   */
48fda62de67a1e John Stultz      2026-03-24 @5103  static void zap_balance_callbacks(struct rq *rq)
48fda62de67a1e John Stultz      2026-03-24  5104  {
48fda62de67a1e John Stultz      2026-03-24  5105  	struct balance_callback *next, *head;
48fda62de67a1e John Stultz      2026-03-24  5106  	bool found = false;
48fda62de67a1e John Stultz      2026-03-24  5107  
48fda62de67a1e John Stultz      2026-03-24  5108  	lockdep_assert_rq_held(rq);
48fda62de67a1e John Stultz      2026-03-24  5109  
48fda62de67a1e John Stultz      2026-03-24  5110  	head = rq->balance_callback;
48fda62de67a1e John Stultz      2026-03-24  5111  	while (head) {
48fda62de67a1e John Stultz      2026-03-24  5112  		if (head == &balance_push_callback)
48fda62de67a1e John Stultz      2026-03-24  5113  			found = true;
48fda62de67a1e John Stultz      2026-03-24  5114  		next = head->next;
48fda62de67a1e John Stultz      2026-03-24  5115  		head->next = NULL;
48fda62de67a1e John Stultz      2026-03-24  5116  		head = next;
48fda62de67a1e John Stultz      2026-03-24  5117  	}
48fda62de67a1e John Stultz      2026-03-24  5118  	rq->balance_callback = found ? &balance_push_callback : NULL;
48fda62de67a1e John Stultz      2026-03-24  5119  }
48fda62de67a1e John Stultz      2026-03-24  5120  

--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki