linux-kernel - [tip: sched/core] sched/uclamp: Fix a bug in propagating uclamp value in new cgroups

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]

Message-ID: <157925572279.396.17594637724980159951.tip-bot2@tip-bot2>
Date:   Fri, 17 Jan 2020 10:08:42 -0000
From:   "tip-bot2 for Qais Yousef" <tip-bot2@...utronix.de>
To:     linux-tip-commits@...r.kernel.org
Cc:     Doug Smythies <dsmythies@...us.net>,
        Qais Yousef <qais.yousef@....com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        x86 <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: [tip: sched/core] sched/uclamp: Fix a bug in propagating uclamp value
 in new cgroups

The following commit has been merged into the sched/core branch of tip:

Commit-ID:     7226017ad37a888915628e59a84a2d1e57b40707
Gitweb:        https://git.kernel.org/tip/7226017ad37a888915628e59a84a2d1e57b40707
Author:        Qais Yousef <qais.yousef@....com>
AuthorDate:    Tue, 24 Dec 2019 11:54:04 
Committer:     Peter Zijlstra <peterz@...radead.org>
CommitterDate: Fri, 17 Jan 2020 10:19:20 +01:00

sched/uclamp: Fix a bug in propagating uclamp value in new cgroups

When a new cgroup is created, the effective uclamp value wasn't updated
with a call to cpu_util_update_eff() that looks at the hierarchy and
update to the most restrictive values.

Fix it by ensuring to call cpu_util_update_eff() when a new cgroup
becomes online.

Without this change, the newly created cgroup uses the default
root_task_group uclamp values, which is 1024 for both uclamp_{min, max},
which will cause the rq to to be clamped to max, hence cause the
system to run at max frequency.

The problem was observed on Ubuntu server and was reproduced on Debian
and Buildroot rootfs.

By default, Ubuntu and Debian create a cpu controller cgroup hierarchy
and add all tasks to it - which creates enough noise to keep the rq
uclamp value at max most of the time. Imitating this behavior makes the
problem visible in Buildroot too which otherwise looks fine since it's a
minimal userspace.

Fixes: 0b60ba2dd342 ("sched/uclamp: Propagate parent clamps")
Reported-by: Doug Smythies <dsmythies@...us.net>
Signed-off-by: Qais Yousef <qais.yousef@....com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Tested-by: Doug Smythies <dsmythies@...us.net>
Link: https://lore.kernel.org/lkml/000701d5b965$361b6c60$a2524520$@net/
---
 kernel/sched/core.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index e7b08d5..d0270b1 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7099,6 +7099,12 @@ static int cpu_cgroup_css_online(struct cgroup_subsys_state *css)

 	if (parent)
 		sched_online_group(tg, parent);
+
+#ifdef CONFIG_UCLAMP_TASK_GROUP
+	/* Propagate the effective uclamp value for the new group */
+	cpu_util_update_eff(css);
+#endif
+
 	return 0;
 }