[PATCH 07/81] sched/rt: Use root_domain of rt_rq not current processor
Herton Ronaldo Krzesinski
herton.krzesinski at canonical.com
Tue Feb 19 18:48:30 UTC 2013
3.5.7.6 -stable review patch. If anyone has any objections, please let me know.
------------------
From: Shawn Bohrer <sbohrer at rgmadvisors.com>
commit aa7f67304d1a03180f463258aa6f15a8b434e77d upstream.
When the system has multiple domains do_sched_rt_period_timer()
can run on any CPU and may iterate over all rt_rq in
cpu_online_mask. This means when balance_runtime() is run for a
given rt_rq that rt_rq may be in a different rd than the current
processor. Thus if we use smp_processor_id() to get rd in
do_balance_runtime() we may borrow runtime from a rt_rq that is
not part of our rd.
This changes do_balance_runtime to get the rd from the passed in
rt_rq ensuring that we borrow runtime only from the correct rd
for the given rt_rq.
This fixes a BUG at kernel/sched/rt.c:687! in __disable_runtime
when we try reclaim runtime lent to other rt_rq but runtime has
been lent to a rt_rq in another rd.
Signed-off-by: Shawn Bohrer <sbohrer at rgmadvisors.com>
Acked-by: Steven Rostedt <rostedt at goodmis.org>
Acked-by: Mike Galbraith <bitbucket at online.de>
Cc: peterz at infradead.org
Link: http://lkml.kernel.org/r/1358186131-29494-1-git-send-email-sbohrer@rgmadvisors.com
Signed-off-by: Ingo Molnar <mingo at kernel.org>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski at canonical.com>
---
kernel/sched/rt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 573e1ca..2a05e56 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -566,7 +566,7 @@ static inline struct rt_bandwidth *sched_rt_bandwidth(struct rt_rq *rt_rq)
static int do_balance_runtime(struct rt_rq *rt_rq)
{
struct rt_bandwidth *rt_b = sched_rt_bandwidth(rt_rq);
- struct root_domain *rd = cpu_rq(smp_processor_id())->rd;
+ struct root_domain *rd = rq_of_rt_rq(rt_rq)->rd;
int i, weight, more = 0;
u64 rt_period;
--
1.7.9.5
More information about the kernel-team
mailing list