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: <1267385046.13676.97.camel@Palantir>
Date:	Sun, 28 Feb 2010 20:24:06 +0100
From:	Raistlin <raistlin@...ux.it>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Chris Friesen <cfriesen@...tel.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Darren Hart <darren@...art.com>,
	Henrik Austad <henrik@...tad.us>,
	Johan Eker <johan.eker@...csson.com>,
	"p.faure" <p.faure@...tech.ch>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Claudio Scordino <claudio@...dence.eu.com>,
	michael trimarchi <trimarchi@...is.sssup.it>,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	Tommaso Cucinotta <t.cucinotta@...up.it>,
	Juri Lelli <juri.lelli@...il.com>,
	Nicola Manica <nicola.manica@...il.com>,
	Luca Abeni <luca.abeni@...tn.it>
Subject: [RFC][PATCH 08/11] sched: send SIGXCPU at -deadline task overruns.

Add to the scheduler the capability of notifying when -deadline tasks
overrun their maximum runtime and/or overcome their scheduling
deadline.

Runtime overruns might be quite common, e.g., due to coarse granularity
execution time accounting resolution or wrong assignment of tasks'
parameters (especially runtime). However, since the scheduler enforces
bandwidth isolation among tasks, this is not at all a threat to other
tasks' schedulability. For this reason, it is not common that a task
wants to be notified about that. Moreover, if we are using the
SCHED_DEADLINE policy with sporadic tasks, or to limit the bandwidth
of not periodic nor sporadic ones, runtime overruns are very likely
to occur at each and every instance, and again they should not be
considered a problem.

On the other hand, a deadline miss in any task means that, even if we
are trying at our best to keep each task isolated and to avoid
reciprocal interference among them, something went very, very bad,
and one task did not manage in consuming its runtime by its deadline.
This is something that should happen only on an oversubscribed
system, and thus being notified when it occurs could be very useful.

The user can specify the signals he wants to be sent to his task
during sched_setscheduler_ex(), raising two specific flags in the
sched_flags field of struct sched_param_ex:
 * SCHED_SIG_RORUN (if he wants to be signaled on runtime overrun),
 * SCHED_SIG_DMISS (if he wants to be signaled on deadline misses).

This patch:
 - adds the logic needed to send SIGXCPU signal to a -deadline task
   in case its actual runtime becomes negative;
 - adds the logic needed to send SIGXCPU signal to a -deadline task
   in case it is still being scheduled while its absolute deadline
   passes.

Signed-off-by: Dario Faggioli <raistlin@...ux.it>
---
 include/linux/sched.h |   18 ++++++++++++++++++
 kernel/sched_dl.c     |   24 ++++++++++++++++++++++++
 2 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index e6c1cda..64a7df2 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -138,6 +138,7 @@ struct sched_param {
  * More information about the algorithm are available in the scheduling
  * class file or in Documentation/.
  */
+
 struct sched_param_ex {
 	int sched_priority;
 	struct timespec sched_runtime;
@@ -146,6 +147,23 @@ struct sched_param_ex {
 	unsigned int sched_flags;
 };
 
+/*
+ * User -deadline flags.
+ *
+ * These flags are exported to userspace so that tasks can try to affect
+ * the scheduler behaviour and/or specifying that they want to be informed
+ * of the occurrence of some events. There are at most 16 of them available
+ * (lowest bits), since values above 0x10000 are reserved for kernel
+ * internal flags.
+ *
+ *  @SCHED_SIG_RORUN	tells us the task wants to be notified whenever
+ *                      a runtime overrun occurs;
+ *  @SCHED_SIG_DMISS	tells us the task wants to be notified whenever
+ *                      a scheduling deadline is missed.
+ */
+#define SCHED_SIG_RORUN		0x0001
+#define SCHED_SIG_DMISS		0x0002
+
 struct exec_domain;
 struct futex_pi_state;
 struct robust_list_head;
diff --git a/kernel/sched_dl.c b/kernel/sched_dl.c
index dee2668..b5dde44 100644
--- a/kernel/sched_dl.c
+++ b/kernel/sched_dl.c
@@ -265,6 +265,14 @@ static void init_dl_timer(struct sched_dl_entity *dl_se)
 	timer->function = dl_timer;
 }
 
+#define dl_se_signal(se, s, msg)					\
+ do {									\
+  struct task_struct *t = dl_task_of(se);				\
+  sigaddset(&t->pending.signal, s);					\
+  set_tsk_thread_flag(t, TIF_SIGPENDING);				\
+  printk(KERN_INFO msg "in %d (%s)\n", task_pid_nr(t), t->comm);	\
+ } while (0)
+
 static
 int dl_runtime_exceeded(struct rq *rq, struct sched_dl_entity *dl_se)
 {
@@ -283,6 +291,22 @@ int dl_runtime_exceeded(struct rq *rq, struct sched_dl_entity *dl_se)
 	if (dmiss)
 		dl_se->runtime -= rq->clock - dl_se->deadline;
 
+	/*
+	 * if the userspace asked for that, we notify about (scheduling)
+	 * deadline misses and runtime overruns via sending SIGXCPU to
+	 * "faulting" task.
+	 *
+	 * Note that (hopefully small) runtime overruns are very likely
+	 * to occur, mainly due to accounting resolution, while missing a
+	 * scheduling deadline should be very rare, and only happen on
+	 * an oversubscribed systems.
+	 */
+	if (unlikely(dmiss && dl_se->flags & SCHED_SIG_DMISS))
+		dl_se_signal(dl_se, SIGXCPU, "Deadline miss");
+
+	if (unlikely(rorun && dl_se->flags & SCHED_SIG_RORUN))
+		dl_se_signal(dl_se, SIGXCPU, "Runtime overrun");
+
 	dequeue_dl_entity(dl_se);
 	if (!start_dl_timer(dl_se, dl_se->deadline)) {
 		if (!rorun)
-- 
1.7.0

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

http://blog.linux.it/raistlin / raistlin@...ga.net /
dario.faggioli@...ber.org

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ