From: Quentin Perret <qperret@google.com>
To: mingo@redhat.com, peterz@infradead.org,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
qais.yousef@arm.com, rickyiu@google.com, wvw@google.com,
patrick.bellasi@matbug.net, xuewen.yan94@gmail.com
Cc: linux-kernel@vger.kernel.org, kernel-team@android.com,
Quentin Perret <qperret@google.com>
Subject: [PATCH v2 3/3] sched: Make uclamp changes depend on CAP_SYS_NICE
Date: Thu, 10 Jun 2021 15:13:06 +0000 [thread overview]
Message-ID: <20210610151306.1789549-4-qperret@google.com> (raw)
In-Reply-To: <20210610151306.1789549-1-qperret@google.com>
There is currently nothing preventing tasks from changing their per-task
clamp values in anyway that they like. The rationale is probably that
system administrators are still able to limit those clamps thanks to the
cgroup interface. However, this causes pain in a system where both
per-task and per-cgroup clamp values are expected to be under the
control of core system components (as is the case for Android).
To fix this, let's require CAP_SYS_NICE to increase per-task clamp
values. This allows unprivileged tasks to lower their requests, but not
increase them, which is consistent with the existing behaviour for nice
values.
Signed-off-by: Quentin Perret <qperret@google.com>
---
kernel/sched/core.c | 55 +++++++++++++++++++++++++++++++++++++++------
1 file changed, 48 insertions(+), 7 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 1d4aedbbcf96..6e24daca8d53 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1430,6 +1430,11 @@ static int uclamp_validate(struct task_struct *p,
if (util_min != -1 && util_max != -1 && util_min > util_max)
return -EINVAL;
+ return 0;
+}
+
+static void uclamp_enable(void)
+{
/*
* We have valid uclamp attributes; make sure uclamp is enabled.
*
@@ -1438,8 +1443,32 @@ static int uclamp_validate(struct task_struct *p,
* scheduler locks.
*/
static_branch_enable(&sched_uclamp_used);
+}
- return 0;
+static bool uclamp_reduce(struct task_struct *p, const struct sched_attr *attr)
+{
+ if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MIN) {
+ int util_min = p->uclamp_req[UCLAMP_MIN].value;
+
+ if (attr->sched_util_min + 1 > util_min + 1)
+ return false;
+
+ if (rt_task(p) && attr->sched_util_min == -1 &&
+ util_min < sysctl_sched_uclamp_util_min_rt_default)
+ return false;
+ }
+
+ if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MAX) {
+ int util_max = p->uclamp_req[UCLAMP_MAX].value;
+
+ if (attr->sched_util_max + 1 > util_max + 1)
+ return false;
+
+ if (attr->sched_util_max == -1 && util_max < uclamp_none(UCLAMP_MAX))
+ return false;
+ }
+
+ return true;
}
static bool uclamp_reset(const struct sched_attr *attr,
@@ -1580,6 +1609,11 @@ static inline int uclamp_validate(struct task_struct *p,
{
return -EOPNOTSUPP;
}
+static inline void uclamp_enable(void) { }
+static bool uclamp_reduce(struct task_struct *p, const struct sched_attr *attr)
+{
+ return true;
+}
static void __setscheduler_uclamp(struct task_struct *p,
const struct sched_attr *attr) { }
static inline void uclamp_fork(struct task_struct *p) { }
@@ -6116,6 +6150,13 @@ static int __sched_setscheduler(struct task_struct *p,
(rt_policy(policy) != (attr->sched_priority != 0)))
return -EINVAL;
+ /* Update task specific "requested" clamps */
+ if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP) {
+ retval = uclamp_validate(p, attr);
+ if (retval)
+ return retval;
+ }
+
/*
* Allow unprivileged RT tasks to decrease priority:
*/
@@ -6165,6 +6206,10 @@ static int __sched_setscheduler(struct task_struct *p,
/* Normal users shall not reset the sched_reset_on_fork flag: */
if (p->sched_reset_on_fork && !reset_on_fork)
return -EPERM;
+
+ /* Can't increase util-clamps */
+ if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP && !uclamp_reduce(p, attr))
+ return -EPERM;
}
if (user) {
@@ -6176,12 +6221,8 @@ static int __sched_setscheduler(struct task_struct *p,
return retval;
}
- /* Update task specific "requested" clamps */
- if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP) {
- retval = uclamp_validate(p, attr);
- if (retval)
- return retval;
- }
+ if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP)
+ uclamp_enable();
if (pi)
cpuset_read_lock();
--
2.32.0.272.g935e593368-goog
next prev parent reply other threads:[~2021-06-10 15:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-10 15:13 [PATCH v2 0/3] A few uclamp fixes Quentin Perret
2021-06-10 15:13 ` [PATCH v2 1/3] sched: Fix UCLAMP_FLAG_IDLE setting Quentin Perret
2021-06-10 19:05 ` Peter Zijlstra
2021-06-11 7:25 ` Quentin Perret
2021-06-17 15:27 ` Dietmar Eggemann
2021-06-21 10:57 ` Quentin Perret
2021-06-10 15:13 ` [PATCH v2 2/3] sched: Skip priority checks with SCHED_FLAG_KEEP_PARAMS Quentin Perret
2021-06-10 19:15 ` Peter Zijlstra
2021-06-11 8:59 ` Quentin Perret
2021-06-11 9:07 ` Quentin Perret
2021-06-11 9:20 ` Peter Zijlstra
2021-06-10 15:13 ` Quentin Perret [this message]
2021-06-11 12:48 ` [PATCH v2 3/3] sched: Make uclamp changes depend on CAP_SYS_NICE Qais Yousef
2021-06-11 13:08 ` Quentin Perret
2021-06-11 13:26 ` Qais Yousef
2021-06-11 13:49 ` Quentin Perret
2021-06-11 14:17 ` Qais Yousef
2021-06-11 14:43 ` Quentin Perret
2021-06-14 15:03 ` Qais Yousef
2021-06-21 10:52 ` Quentin Perret
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210610151306.1789549-4-qperret@google.com \
--to=qperret@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=patrick.bellasi@matbug.net \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=rickyiu@google.com \
--cc=vincent.guittot@linaro.org \
--cc=wvw@google.com \
--cc=xuewen.yan94@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.