From: Peter Zijlstra <peterz@infradead.org>
To: Qais Yousef <qais.yousef@arm.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Doug Anderson <dianders@chromium.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Patrick Bellasi <patrick.bellasi@matbug.net>,
Chris Redpath <chris.redpath@arm.com>,
Lukasz Luba <lukasz.luba@arm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 3/3] sched/uclamp: Fix a deadlock when enabling uclamp static key
Date: Fri, 24 Jul 2020 12:41:20 +0200 [thread overview]
Message-ID: <20200724104120.GY10769@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20200724094650.hgya5j7i7lbhrocy@e107158-lin.cambridge.arm.com>
On Fri, Jul 24, 2020 at 10:46:50AM +0100, Qais Yousef wrote:
> On 07/24/20 11:12, Peter Zijlstra wrote:
> > On Thu, Jul 16, 2020 at 12:03:47PM +0100, Qais Yousef wrote:
> >
> > I've trimmed the Changelog to read like:
>
> +1
>
> Should we mention the ordering issue too? Or maybe I misinterpreted the
> 'Possible unsafe locking scenario' part?
The lock inversion was, imo, secondary. It only existed because of the
impossible lock ordering -- taking a blocking lock inside an atomic
lock. Fixing the first, avoids the second etc.. So I left it out.
> This should work, but you'll need to sprinkle ifdef around the key. Or move it
> to uclamp_validate()
Indeed, the patch now reads like:
---
Subject: sched/uclamp: Fix a deadlock when enabling uclamp static key
From: Qais Yousef <qais.yousef@arm.com>
Date: Thu, 16 Jul 2020 12:03:47 +0100
From: Qais Yousef <qais.yousef@arm.com>
The following splat was caught when setting uclamp value of a task:
BUG: sleeping function called from invalid context at ./include/linux/percpu-rwsem.h:49
cpus_read_lock+0x68/0x130
static_key_enable+0x1c/0x38
__sched_setscheduler+0x900/0xad8
Fix by ensuring we enable the key outside of the critical section in
__sched_setscheduler()
Fixes: 46609ce22703 ("sched/uclamp: Protect uclamp fast path code with static key")
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200716110347.19553-4-qais.yousef@arm.com
---
kernel/sched/core.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1252,6 +1252,15 @@ static int uclamp_validate(struct task_s
if (upper_bound > SCHED_CAPACITY_SCALE)
return -EINVAL;
+ /*
+ * We have valid uclamp attributes; make sure uclamp is enabled.
+ *
+ * We need to do that here, because enabling static branches is a
+ * blocking operation which obviously cannot be done while holding
+ * scheduler locks.
+ */
+ static_branch_enable(&sched_uclamp_used);
+
return 0;
}
@@ -1282,8 +1291,6 @@ static void __setscheduler_uclamp(struct
if (likely(!(attr->sched_flags & SCHED_FLAG_UTIL_CLAMP)))
return;
- static_branch_enable(&sched_uclamp_used);
-
if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MIN) {
uclamp_se_set(&p->uclamp_req[UCLAMP_MIN],
attr->sched_util_min, true);
next prev parent reply other threads:[~2020-07-24 10:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-16 11:03 [PATCH v7 0/3] sched/uclamp: new sysctl for default RT boost value Qais Yousef
2020-07-16 11:03 ` [PATCH v7 1/3] sched/uclamp: Add a new sysctl to control RT default " Qais Yousef
2020-07-24 8:54 ` Peter Zijlstra
2020-07-24 9:16 ` Qais Yousef
2020-07-29 12:02 ` [tip: sched/core] " tip-bot2 for Qais Yousef
2020-07-16 11:03 ` [PATCH v7 2/3] Documentation/sysctl: Document uclamp sysctl knobs Qais Yousef
2020-07-29 12:02 ` [tip: sched/core] " tip-bot2 for Qais Yousef
2020-07-16 11:03 ` [PATCH v7 3/3] sched/uclamp: Fix a deadlock when enabling uclamp static key Qais Yousef
2020-07-16 11:13 ` Qais Yousef
2020-07-23 15:51 ` Qais Yousef
2020-07-24 9:12 ` Peter Zijlstra
2020-07-24 9:46 ` Qais Yousef
2020-07-24 10:41 ` Peter Zijlstra [this message]
2020-07-24 10:50 ` Qais Yousef
2020-07-29 12:02 ` [tip: sched/core] " tip-bot2 for Qais Yousef
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=20200724104120.GY10769@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bsegall@google.com \
--cc=chris.redpath@arm.com \
--cc=dianders@chromium.org \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=patrick.bellasi@matbug.net \
--cc=qais.yousef@arm.com \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®