From: tip-bot for Juri Lelli <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: torvalds@linux-foundation.org, peterz@infradead.org,
linux-kernel@vger.kernel.org, tglx@linutronix.de,
raistlin@linux.it, juri.lelli@arm.com, mingo@kernel.org,
hpa@zytor.com, daniel.wagner@bmw-carit.de, fchecconi@gmail.com,
michael@amarulasolutions.com
Subject: [tip:sched/core] sched/deadline: Don' t replenish from a !SCHED_DEADLINE entity
Date: Tue, 28 Oct 2014 04:01:49 -0700 [thread overview]
Message-ID: <tip-64be6f1f5f710f5995d41caf8a1767fe6d2b5a87@git.kernel.org> (raw)
In-Reply-To: <1414142198-18552-4-git-send-email-juri.lelli@arm.com>
Commit-ID: 64be6f1f5f710f5995d41caf8a1767fe6d2b5a87
Gitweb: http://git.kernel.org/tip/64be6f1f5f710f5995d41caf8a1767fe6d2b5a87
Author: Juri Lelli <juri.lelli@arm.com>
AuthorDate: Fri, 24 Oct 2014 10:16:37 +0100
Committer: Ingo Molnar <mingo@kernel.org>
CommitDate: Tue, 28 Oct 2014 10:46:00 +0100
sched/deadline: Don't replenish from a !SCHED_DEADLINE entity
In the deboost path, right after the dl_boosted flag has been
reset, we can currently end up replenishing using -deadline
parameters of a !SCHED_DEADLINE entity. This of course causes
a bug, as those parameters are empty.
In the case depicted above it is safe to simply bail out, as
the deboosted task is going to be back to its original scheduling
class anyway.
Reported-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Signed-off-by: Juri Lelli <juri.lelli@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: vincent@legout.info
Cc: Dario Faggioli <raistlin@linux.it>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Cc: Fabio Checconi <fchecconi@gmail.com>
Link: http://lkml.kernel.org/r/1414142198-18552-4-git-send-email-juri.lelli@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
kernel/sched/deadline.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 256e577..92279ea 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -847,8 +847,19 @@ static void enqueue_task_dl(struct rq *rq, struct task_struct *p, int flags)
* smaller than our one... OTW we keep our runtime and
* deadline.
*/
- if (pi_task && p->dl.dl_boosted && dl_prio(pi_task->normal_prio))
+ if (pi_task && p->dl.dl_boosted && dl_prio(pi_task->normal_prio)) {
pi_se = &pi_task->dl;
+ } else if (!dl_prio(p->normal_prio)) {
+ /*
+ * Special case in which we have a !SCHED_DEADLINE task
+ * that is going to be deboosted, but exceedes its
+ * runtime while doing so. No point in replenishing
+ * it, as it's going to return back to its original
+ * scheduling class after this.
+ */
+ BUG_ON(!p->dl.dl_boosted || flags != ENQUEUE_REPLENISH);
+ return;
+ }
/*
* If p is throttled, we do nothing. In fact, if it exhausted
next prev parent reply other threads:[~2014-10-28 11:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-24 9:16 [PATCH 0/4] Fix various bits of AC and PI for SCHED_DEADLINE Juri Lelli
2014-10-24 9:16 ` [PATCH 1/4] sched/deadline: fix bandwidth check/update when migrating tasks between exclusive cpusets Juri Lelli
2014-10-24 9:16 ` [PATCH 2/4] sched/deadline: ensure that updates to exclusive cpusets don't break AC Juri Lelli
2014-10-24 9:16 ` [PATCH 3/4] sched/deadline: don't replenish from a !SCHED_DEADLINE entity Juri Lelli
2014-10-28 11:01 ` tip-bot for Juri Lelli [this message]
2014-10-24 9:16 ` [PATCH 4/4] sched/deadline: fix races between rt_mutex_setprio and dl_task_timer Juri Lelli
2014-10-28 11:02 ` [tip:sched/core] sched/deadline: Fix races between rt_mutex_setprio() and dl_task_timer() tip-bot for Juri Lelli
2014-10-24 11:34 ` [PATCH 0/4] Fix various bits of AC and PI for SCHED_DEADLINE Daniel Wagner
2014-10-24 13:21 ` Juri Lelli
2014-10-24 13:39 ` Peter Zijlstra
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=tip-64be6f1f5f710f5995d41caf8a1767fe6d2b5a87@git.kernel.org \
--to=tipbot@zytor.com \
--cc=daniel.wagner@bmw-carit.de \
--cc=fchecconi@gmail.com \
--cc=hpa@zytor.com \
--cc=juri.lelli@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=michael@amarulasolutions.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=raistlin@linux.it \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 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.