Commit-ID: aa7f67304d1a03180f463258aa6f15a8b434e77d Gitweb: http://git.kernel.org/tip/aa7f67304d1a03180f463258aa6f15a8b434e77d Author: Shawn Bohrer <sbohrer@xxxxxxxxxxxxxxx> AuthorDate: Mon, 14 Jan 2013 11:55:31 -0600 Committer: Ingo Molnar <mingo@xxxxxxxxxx> CommitDate: Fri, 25 Jan 2013 08:20:47 +0100 sched/rt: Use root_domain of rt_rq not current processor 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@xxxxxxxxxxxxxxx> Acked-by: Steven Rostedt <rostedt@xxxxxxxxxxx> Acked-by: Mike Galbraith <bitbucket@xxxxxxxxx> Cc: peterz@xxxxxxxxxxxxx Cc: <stable@xxxxxxxxxx> Link: http://lkml.kernel.org/r/1358186131-29494-1-git-send-email-sbohrer@xxxxxxxxxxxxxxx Signed-off-by: Ingo Molnar <mingo@xxxxxxxxxx> --- 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 418feb0..4f02b28 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; -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html