[PATCH openEuler-1.0-LTS 0/2] Fix rt warning

Zheng Zucheng (2): sched/rt: Fix rt_runtime leaks with cpu hotplug sched: Replace WARN_ON_ONCE to printk_deferred_once kernel/sched/rt.c | 14 ++++++++++---- kernel/sched/sched.h | 2 +- 2 files changed, 11 insertions(+), 5 deletions(-) -- 2.34.1

hulk inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBHFLI -------------------------------- When using cgroup rt_bandwidth with RT_RUNTIME_SHARE dynamic change, if there are cpu hotplug and RT_RUNTIME_SHARE changing concurrently, the warning in __disable_runtime may occur: WARNING: CPU: 1 PID: 1434 at kernel/sched/rt.c:806 __disable_runtime+0x354/0x370 RIP: 0010:__disable_runtime+0x354/0x370 Call Trace: ? __warn+0x9b/0x140 ? __disable_runtime+0x354/0x370 rq_offline_rt+0x3c/0x120 set_rq_offline.part.0+0x3c/0xc0 rq_attach_root+0x1e5/0x1f0 cpu_attach_domain+0x1eb/0x250 detach_destroy_domains+0xaf/0x1a0 partition_sched_domains_locked+0x321/0x450 rebuild_sched_domains_locked+0x16d/0x430 ? generate_sched_domains+0x920/0x920 cpuset_hotplug_workfn+0x451/0xe20 ? cpuset_hotplug_update_tasks+0x530/0x530 ? do_raw_spin_lock+0x1b0/0x1b0 ? fill_page_cache_func+0xf0/0xf0 process_one_work+0x4b2/0x8e0 ? pwq_dec_nr_in_flight+0x100/0x100 ? __list_add_valid+0x36/0xe0 worker_thread+0x8b/0x580 The triggering scenario is as follows:: CPU0 CPU1 ----- ----- set_rq_offline(rq) __disable_runtime(rq) (1) NO_RT_RUNTIME_SHARE do_sched_rt_period_timer(2) RT_RUNTIME_SHARE do_balance_runtime (3) set_rq_online(rq) __enable_runtime(rq) (4) In step(1) rt_rq0->rt_runtime is set to RUNTIME_DISABLED, and this rt_rq's runtime is not supposed to change until its rq gets online. However, in step(2) timer trigger set rt_rq0->rt_runtime to rt_b->rt_runtime. Then, in step(3) rt_rq0->rt_runtime is not RUNTIME_INF or RUNTIME_DISABLED, so others can borrow rt_runtime from it. Finally, in step(4) the rq gets online, so its rt_rq0's runtime is set to rt_b->rt_runtime again, and since then the total rt_runtime in the domain is increased by this way. After these steps, when offline cpu and rebuild sched_domain will offline all rq, and the last rq will find the rt_runtime is increased but nowhere to return. To fix this, when rt bandwidth timer expires, the rt_rq->rt_runtime of offline CPU is not updated before online. Fixes: 5cb5bd378953 ("sched/rt: Fix rt_runtime leaks with cpu hotplug and RT_RUNTIME_SHARE") Signed-off-by: Zheng Zucheng <zhengzucheng@huawei.com> --- kernel/sched/rt.c | 9 ++++++--- kernel/sched/sched.h | 2 +- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 9093fa9f8fdc..3bc68ceedba4 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -715,7 +715,8 @@ static void __disable_runtime(struct rq *rq) * exactly the right amount of runtime to take out. */ if (rt_rq->rt_runtime == RUNTIME_INF || - rt_rq->rt_runtime == rt_b->rt_runtime) + rt_rq->rt_runtime == rt_b->rt_runtime || + rt_rq->rt_runtime == RUNTIME_DISABLED) goto balanced; raw_spin_unlock(&rt_rq->rt_runtime_lock); @@ -844,7 +845,9 @@ static int do_sched_rt_period_timer(struct rt_bandwidth *rt_b, int overrun) * can be time-consuming. Try to avoid it when possible. */ raw_spin_lock(&rt_rq->rt_runtime_lock); - if (!sched_feat(RT_RUNTIME_SHARE) && rt_rq->rt_runtime != RUNTIME_INF) + if (!sched_feat(RT_RUNTIME_SHARE) && + rt_rq->rt_runtime != RUNTIME_INF && + rt_rq->rt_runtime != RUNTIME_DISABLED) rt_rq->rt_runtime = rt_b->rt_runtime; skip = !rt_rq->rt_time && !rt_rq->rt_nr_running; raw_spin_unlock(&rt_rq->rt_runtime_lock); @@ -922,7 +925,7 @@ static int sched_rt_runtime_exceeded(struct rt_rq *rt_rq) balance_runtime(rt_rq); runtime = sched_rt_runtime(rt_rq); - if (runtime == RUNTIME_INF) + if (runtime == RUNTIME_INF || runtime == RUNTIME_DISABLED) return 0; if (rt_rq->rt_time > runtime) { diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index 80e9d254ab7c..b4f368ec4d87 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -166,7 +166,7 @@ static inline void cpu_load_update_active(struct rq *this_rq) { } /* * Single value that denotes runtime is disabled, and it should not be used. */ -#define RUNTIME_DISABLED (-2ULL) +#define RUNTIME_DISABLED ((u64)~1ULL) static inline int idle_policy(int policy) { -- 2.34.1

hulk inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IBHFLI -------------------------------- AA deadlock may occur when WARN_ON_ONCE() is invoked in the scheduler, so replace WARN_ON_ONCE() to printk_deferred_once() Fixes: 45fb4e58b06c ("sched/all: Change all BUG_ON() instances in the scheduler to WARN_ON_ONCE()") Signed-off-by: Zheng Zucheng <zhengzucheng@huawei.com> --- kernel/sched/rt.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 3bc68ceedba4..7f512203d9e7 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -762,7 +762,10 @@ static void __disable_runtime(struct rq *rq) * We cannot be left wanting - that would mean some runtime * leaked out of the system. */ - WARN_ON_ONCE(want); + if (unlikely(want != 0)) + printk_deferred_once(KERN_WARNING + "WARNING: runtime leaks possible want=%lld cpu=%d\n", + want, cpu_of(rq)); balanced: /* * Disable all the borrow logic by marking runtime disabled. -- 2.34.1

反馈: 您发送到kernel@openeuler.org的补丁/补丁集,已成功转换为PR! PR链接地址: https://gitee.com/openeuler/kernel/pulls/14850 邮件列表地址:https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/C... FeedBack: The patch(es) which you have sent to kernel@openeuler.org mailing list has been converted to a pull request successfully! Pull request link: https://gitee.com/openeuler/kernel/pulls/14850 Mailing list address: https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/C...
participants (2)
-
patchwork bot
-
Zheng Zucheng