linux-kernel - [PATCH] sched/rt: rto_next_cpu: Skip CPUs with NEED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20251121014004.564508-1-chenjinghuang2@huawei.com>
Date: Fri, 21 Nov 2025 01:40:04 +0000
From: Chen Jinghuang <chenjinghuang2@...wei.com>
To: <mingo@...hat.com>
CC: <peterz@...radead.org>, <juri.lelli@...hat.com>,
	<vincent.guittot@...aro.org>, <dietmar.eggemann@....com>,
	<rostedt@...dmis.org>, <bsegall@...gle.com>, <mgorman@...e.de>,
	<vschneid@...hat.com>, <linux-kernel@...r.kernel.org>
Subject: [PATCH] sched/rt: rto_next_cpu: Skip CPUs with NEED_RESCHED

CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound
RT task, and a CFS task stuck in kernel space. When other CPUs switch from
RT to non-RT tasks, RT load balancing (LB) is triggered; with
HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution
of rto_push_irq_work_func. During push_rt_task on CPU0,
if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED
and after the push operation completes, CPU0 calls rto_next_cpu().
Since only CPU0 is overloaded in this scenario, rto_next_cpu() should
ideally return -1 (no further IPI needed).

However, multiple CPUs invoking tell_cpu_to_push() during LB increments
rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between
rd->rto_loop and rd->rto_loop_next forces rto next_cpu() to restart its
search from -1. With CPU0 remaining overloaded(""satisfying rt_nr_migratory
&& rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to
itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and
other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop,
wasting CPU cycles on unnecessary interrupt handling.

The triggering scenario is as follows:

         cpu0	        	   cpu1               	      cpu2
                   	        pull_rt_task
	                      tell_cpu_to_push
                 <------------irq_work_queue_on
rto_push_irq_work_func
       push_rt_task
    resched_curr(rq)                                      pull_rt_task
    rto_next_cpu                                        tell_cpu_to_push
     			 <-------------------------- atomic_inc(rto_loop_next)
rd->rto_loop != next
     rto_next_cpu
   irq_work_queue_on
rto_push_irq_work_func

Fix redundant self-IPI/cross-CPU IPI when target CPU already has a pending
reschedule, making the IPI unnecessary.

Signed-off-by: Chen Jinghuang <chenjinghuang2@...wei.com>
---
 kernel/sched/rt.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 7936d4333731..29ce1af9f121 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -2123,8 +2123,20 @@ static int rto_next_cpu(struct root_domain *rd)

 		rd->rto_cpu = cpu;

-		if (cpu < nr_cpu_ids)
+		if (cpu < nr_cpu_ids) {
+			struct task_struct *t;
+			struct rq *rq = cpu_rq(cpu);
+
+			rcu_read_lock();
+			t = rcu_dereference(rq->curr);
+			if (test_tsk_need_resched(t)) {
+				rcu_read_unlock();
+				continue;
+			}
+			rcu_read_unlock();
+
 			return cpu;
+		}

 		rd->rto_cpu = -1;

-- 
2.34.1