linux-kernel - [PATCH] sched/rt: Use prev_sum_exec_runtime to record the timeslice start time

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: <20250809184418.2012584-1-jackzxcui1989@163.com>
Date: Sun, 10 Aug 2025 02:44:18 +0800
From: Xin Zhao <jackzxcui1989@....com>
To: mingo@...hat.com,
	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
Cc: linux-kernel@...r.kernel.org,
	Xin Zhao <jackzxcui1989@....com>
Subject: [PATCH] sched/rt: Use prev_sum_exec_runtime to record the timeslice start time

For tasks in the fair scheduling class, we can register a sched_stat_runtime
tracepoint. When a periodic tick interrupt occurs, we can calculate the
difference between prev_sum_exec_runtime and sum_exec_runtime to determine
how long the current time slice has been running. However, for RT scheduling
class tasks, this is not possible because the value of prev_sum_exec_runtime
is not set when scheduling RT tasks, making it impossible to perform such a
difference calculation.
This detection is very meaningful because if a real-time task runs for too
long in a single time slice, it can significantly impact the overall system
state. For instance, it may prevent the rcu's gp_seq from updating in a
timely manner, and it may cause kworker and other system-level tasks to be
unable to get scheduled on time, which can further affect the entire system's
operation. Early identification of this issue can help the system make
functional safety decisions sooner, especially in the context of automotive
intelligent driving systems.
This change can be combined with tracepoints to extend the sensitive
detection of long-running time slices from fair scheduling class tasks to
RT tasks using the existing tick mechanism of the system. Without this
modification, we would only be able to check at a relatively later time,
such as during sched_switch, and RT tasks can sometimes run for a long time
when issues arise. Discovering system problems only during task switching is
not always a wise choice. Of course, we could use other means, such as adding
a high-resolution timer in a hard interrupt context to perform this detection,
but high-frequency hrtimers can impose a certain burden on the system. If we
can leverage the existing tick mechanism for such checks, it would be a
better approach.

Signed-off-by: Xin Zhao <jackzxcui1989@....com>
---
 kernel/sched/rt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 7936d4333..8e4093a17 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1641,6 +1641,7 @@ static inline void set_next_task_rt(struct rq *rq, struct task_struct *p, bool f
 	struct sched_rt_entity *rt_se = &p->rt;
 	struct rt_rq *rt_rq = &rq->rt;

+	p->se.prev_sum_exec_runtime = p->se.sum_exec_runtime;
 	p->se.exec_start = rq_clock_task(rq);
 	if (on_rt_rq(&p->rt))
 		update_stats_wait_end_rt(rt_rq, rt_se);
-- 
2.34.1