[PATCH v5 10/29] sched/deadline: Reset the donor's runtime at a deboost in the class

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

A task boosted by a deadline waiter runs on the waiter's reservation.
Commit 2d3d891d3344 ("sched/deadline: Add SCHED_DEADLINE inheritance
logic") uses the waiter's parameters "during the whole period it holds
the pi-lock".

A task that leaves the class at its deboost has its deadline and
runtime checked. "sched/deadline: Reset the deadline and the runtime
with the parameters" resets them for a task with no parameters. For a
task with parameters, task_non_contending() clears them if the runtime
does not fit the task's own bandwidth.

But a deadline task stays in the class. rt_mutex_setprio() only clears
dl_boosted. enqueue_dl_entity() keeps a deadline that is ahead. So the
task runs on the waiter's runtime until that deadline. A task that
sched_setattr() makes SCHED_DEADLINE while boosted ends the same way.

In one period, the task can then run what the waiter left on top of
its own runtime. Other deadline tasks can miss deadlines.

The task's own reservation never gives it a runtime above dl_runtime.
Fix this by resetting the deadline and the runtime when a boost ends in
the class with a runtime above dl_runtime. The next enqueue then starts
a new period. A runtime of dl_runtime or less is kept, with its
deadline. By that deadline, the task then runs at most one runtime of
its own. A new period would give it a full runtime.

The Sashiko AI review of the fourth posting found the sched_setattr()
case. The deboost_in_class_resets_period case of deadline_bw_test,
added later in this series, tests it.

Fixes: 2d3d891d3344 ("sched/deadline: Add SCHED_DEADLINE inheritance logic")
Cc: stable@vger.kernel.org
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
---
 kernel/sched/core.c     |  2 +-
 kernel/sched/deadline.c | 16 ++++++++++++++++
 kernel/sched/sched.h    |  1 +
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index e4d299acb1fc..bf722f5ff97e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7898,7 +7898,7 @@ void rt_mutex_setprio(struct task_struct *p, struct task_struct *pi_task)
 				dl_boost(&p->dl, &pi->dl);
 				scope->flags |= ENQUEUE_REPLENISH;
 			} else {
-				p->dl.dl_boosted = 0;
+				dl_deboost(&p->dl);
 			}
 		} else if (rt_prio(prio)) {
 			if (dl_prio(oldprio))
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index cc43c5eeae51..e6c55afcfd01 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -118,6 +118,22 @@ void dl_boost(struct sched_dl_entity *dl_se, const struct sched_dl_params *param
 	dl_se->pi_params = *params;
 	dl_se->dl_boosted = 1;
 }
+
+/*
+ * End the boost of @dl_se, a task that stays in the class. Its own
+ * reservation never gives it a runtime above dl_runtime. A larger runtime
+ * is what the donor left. In that case, reset the runtime and the
+ * deadline. The next enqueue then starts a new period. The caller holds
+ * the rq lock and the pi_lock of the task.
+ */
+void dl_deboost(struct sched_dl_entity *dl_se)
+{
+	if (dl_se->dl_boosted && dl_se->runtime > (s64)dl_se->dl_runtime) {
+		dl_se->deadline = 0;
+		dl_se->runtime = 0;
+	}
+	dl_se->dl_boosted = 0;
+}
 #else /* !CONFIG_RT_MUTEXES: */
 static inline bool is_dl_boosted(struct sched_dl_entity *dl_se)
 {
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index a06cf2e0d983..d0f5ed98ef48 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -358,6 +358,7 @@ extern int  sched_dl_overflow(struct task_struct *p, int policy, const struct sc
 extern void __setparam_dl(struct task_struct *p, const struct sched_attr *attr);
 #ifdef CONFIG_RT_MUTEXES
 extern void dl_boost(struct sched_dl_entity *dl_se, const struct sched_dl_params *params);
+extern void dl_deboost(struct sched_dl_entity *dl_se);
 #endif
 extern void __getparam_dl(struct task_struct *p, struct sched_attr *attr, unsigned int flags);
 extern bool __checkparam_dl(const struct sched_attr *attr);
-- 
2.47.3