linux-kernel - [RFC 34/60] cosched: Add rq_of() variants for different use cases

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: <20180907214047.26914-35-jschoenh@amazon.de>
Date:   Fri,  7 Sep 2018 23:40:21 +0200
From:   Jan H. Schönherr <jschoenh@...zon.de>
To:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     Jan H. Schönherr <jschoenh@...zon.de>,
        linux-kernel@...r.kernel.org
Subject: [RFC 34/60] cosched: Add rq_of() variants for different use cases

The rq_of() function is used everywhere. With the introduction of
hierarchical runqueues, we could modify rq_of() to return the
corresponding queue. In fact, no change would be necessary for that.

However, many code paths do not handle a hierarchical runqueue
adequately. Thus, we introduce variants of rq_of() to catch and
handle these code paths on a case by case basis.

The normal rq_of() will complain loudly if used with a hierarchical
runqueue. If a code path was audited for hierarchical use, it can be
switched to hrq_of(), which returns the proper hierarchical runqueue,
or to cpu_rq_of(), which returns the leader's CPU runqueue.

Signed-off-by: Jan H. Schönherr <jschoenh@...zon.de>
---
 kernel/sched/fair.c | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 8cba7b8fb6bd..24d01bf8f796 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -249,9 +249,44 @@ const struct sched_class fair_sched_class;
 
 #ifdef CONFIG_FAIR_GROUP_SCHED
 
+/* Variant of rq_of() that always returns a per-CPU runqueue */
+static inline struct rq *cpu_rq_of(struct cfs_rq *cfs_rq)
+{
+#ifdef CONFIG_COSCHEDULING
+	if (cfs_rq->sdrq.data->level) {
+		struct rq *rq = cpu_rq(cfs_rq->sdrq.data->leader);
+
+		/* We should have this lock already. */
+		lockdep_assert_held(&rq->lock);
+		return rq;
+	}
+#endif
+	return cfs_rq->rq;
+}
+
 /* cpu runqueue to which this cfs_rq is attached */
 static inline struct rq *rq_of(struct cfs_rq *cfs_rq)
 {
+#ifdef CONFIG_COSCHEDULING
+	if (SCHED_WARN_ON(cfs_rq->sdrq.data->level)) {
+		/*
+		 * This should be only called for the bottom level.
+		 * If not, then it's an indicator of a not yet adjusted
+		 * code path. Return the CPU runqueue as this is more likely
+		 * to work than the proper hierarchical runqueue.
+		 *
+		 * Note, that we don't necessarily have the lock for
+		 * this bottom level, which may lead to weird issues.
+		 */
+		return cpu_rq_of(cfs_rq);
+	}
+#endif
+	return cfs_rq->rq;
+}
+
+/* Hierarchical variant of rq_of() */
+static inline struct rq *hrq_of(struct cfs_rq *cfs_rq)
+{
 	return cfs_rq->rq;
 }
 
-- 
2.9.3.1.gcba166c.dirty