linux-kernel - Re: [RFC] sched/deadline: Prevent rt

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140221103715.GP9987@twins.programming.kicks-ass.net>
Date:	Fri, 21 Feb 2014 11:37:15 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Kirill Tkhai <tkhai@...dex.ru>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Juri Lelli <juri.lelli@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [RFC] sched/deadline: Prevent rt_time growth to infinity

On Thu, Feb 20, 2014 at 02:16:00AM +0400, Kirill Tkhai wrote:
> Since deadline tasks share rt bandwidth, we must care about
> bandwidth timer set. Otherwise rt_time may grow up to infinity
> in update_curr_dl(), if there are no other available RT tasks
> on top level bandwidth.
> 
> I'm going to decide the problem the way below. Almost untested
> because of I skipped almost all of recent patches which haveto be applied from lkml.
> 
> Please say, if I skipped anything in idea. Maybe better put
> start_top_rt_bandwidth() into set_curr_task_dl()?

How about we only increment rt_time when there's an RT bandwidth timer
active?


---
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -568,6 +568,12 @@ static inline struct rt_bandwidth *sched
 
 #endif /* CONFIG_RT_GROUP_SCHED */
 
+bool sched_rt_bandwidth_active(struct rt_rq *rt_rq)
+{
+	struct rt_bandwidth *rt_b = sched_rt_bandwidth(rt_rq);
+	return hrtimer_active(&rt_b->rt_period_timer);
+}
+
 #ifdef CONFIG_SMP
 /*
  * We ran out of runtime, see if we can borrow some from our neighbours.
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -587,6 +587,8 @@ int dl_runtime_exceeded(struct rq *rq, s
 	return 1;
 }
 
+extern bool sched_rt_bandwidth_active(struct rt_rq *rt_rq);
+
 /*
  * Update the current task's runtime statistics (provided it is still
  * a -deadline task and has not been removed from the dl_rq).
@@ -650,11 +652,13 @@ static void update_curr_dl(struct rq *rq
 		struct rt_rq *rt_rq = &rq->rt;
 
 		raw_spin_lock(&rt_rq->rt_runtime_lock);
-		rt_rq->rt_time += delta_exec;
 		/*
 		 * We'll let actual RT tasks worry about the overflow here, we
-		 * have our own CBS to keep us inline -- see above.
+		 * have our own CBS to keep us inline; only account when RT
+		 * bandwidth is relevant.
 		 */
+		if (sched_rt_bandwidth_active(rt_rq))
+			rt_rq->rt_time += delta_exec;
 		raw_spin_unlock(&rt_rq->rt_runtime_lock);
 	}
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/