linux-kernel - [PATCH] sched: Fix 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>] [day] [month] [year] [list]

Date:   Thu, 25 Aug 2016 20:29:59 +0900
From:   "Yin-goo Yim" <ygyim@...kuk.ac.kr>
To:     <mingo@...hat.com>, <peterz@...radead.org>
Cc:     <linux-kernel@...r.kernel.org>, <tj@...nel.org>,
        <torvalds@...ux-foundation.org>, <jinh@...kuk.ac.kr>
Subject: [PATCH] sched: Fix rt_task to work properly

Hi,
I am a graduate student of System Software Lab. at Konkuk University

We found that the rt_task() function returns true even if the task is a
deadline task scheduled by SCHED_DEADLINE, because the function simply
checks whether the priority of the task is smaller than 100. As the
priority of deadline tasks is smaller than 0, the rt_task() function
returns true for deadline tasks. However, there exists a separate function
(i.e., dl_task()) to check if a task is a deadline task. That is, we
believe that rt_task() has to return true only if the task is an rt task
scheduled by SCHED_FIFO or SCHED_RR, while giving false for deadline tasks.

This ambiguity of rt_task() is causing a strange problem in cgroup. More
precisely, we found that -EBUSY was always returned when we tried to run a
task group that consisted of rt tasks together with a deadline task. This
happened regardless of how much CPU resources were reserved by cgroups and

deadline tasks. It turns out that tg_rt_schedulable() returns ?EBUSY by the
following conditional statement for deadline tasks:
if (rt_bandwidth_enabled() && !runtime && tg_has_rt_tasks(tg))
return -EBUSY;
For deadline tasks, tg_has_rt_tasks() in the above statement has to return
false. However, the current implementation of rt_task() called by
tg_has_rt_tasks() only checks whether the priority of tasks are smaller
than 100; thus, it returns true even for deadline tasks that have a minus
number.

Our patch is to fix this problem by checking the priority of tasks more
precisely (i.e., 0 < priority < 100) in rt_task().

Signed-off-by: Yin-goo Yim <ygyim@...kuk.ac.kr>
---
include/linux/sched/deadline.h | 8 +-------
include/linux/sched/prio.h     | 8 ++++++++
include/linux/sched/rt.h       | 2 +-
3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/include/linux/sched/deadline.h b/include/linux/sched/deadline.h
index 9089a2a..3e38564 100644
--- a/include/linux/sched/deadline.h
+++ b/include/linux/sched/deadline.h
@@ -1,13 +1,7 @@
#ifndef _SCHED_DEADLINE_H
#define _SCHED_DEADLINE_H

-/*
- * SCHED_DEADLINE tasks has negative priorities, reflecting
- * the fact that any of them has higher prio than RT and
- * NORMAL/BATCH tasks.
- */
-
-#define MAX_DL_PRIO 0
+#include <linux/sched/prio.h>

static inline int dl_prio(int prio)
{
diff --git a/include/linux/sched/prio.h b/include/linux/sched/prio.h
index d9cf5a5..3faddc6 100644
--- a/include/linux/sched/prio.h
+++ b/include/linux/sched/prio.h
@@ -25,6 +25,14 @@
#define DEFAULT_PRIO (MAX_RT_PRIO + NICE_WIDTH / 2)

/*
+ * SCHED_DEADLINE tasks has negative priorities, reflecting
+ * the fact that any of them has higher prio than RT and
+ * NORMAL/BATCH tasks.
+ */
+
+#define MAX_DL_PRIO 0
+
+/*
  * Convert user-nice values [ -20 ... 0 ... 19 ]
  * to static priority [ MAX_RT_PRIO..MAX_PRIO-1 ],
  * and back.
diff --git a/include/linux/sched/rt.h b/include/linux/sched/rt.h
index a30b172..062cddb 100644
--- a/include/linux/sched/rt.h
+++ b/include/linux/sched/rt.h
@@ -5,7 +5,7 @@

static inline int rt_prio(int prio)
{
- if (unlikely(prio < MAX_RT_PRIO))
+ if (unlikely(prio < MAX_RT_PRIO && prio > MAX_DL_PRIO))
  return 1;
  return 0;
}