From: Peter Zijlstra <peterz@infradead.org>
To: "Chen, Yu C" <yu.c.chen@intel.com>
Cc: longman@redhat.com, chenridong@huaweicloud.com,
juri.lelli@redhat.com, vincent.guittot@linaro.org,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
tj@kernel.org, hannes@cmpxchg.org, mkoutny@suse.com,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
jstultz@google.com, kprateek.nayak@amd.com, qyousef@layalina.io,
mingo@kernel.org
Subject: Re: [PATCH v3 7/7] sched/eevdf: Move to a single runqueue
Date: Fri, 26 Jun 2026 13:40:16 +0200 [thread overview]
Message-ID: <20260626114016.GZ42921@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <a22eea2b-4c4a-4623-9a44-d7b18c0c91c8@intel.com>
On Sat, Jun 20, 2026 at 11:54:22AM +0800, Chen, Yu C wrote:
> A divide-by-zero crash is observed when running hackbench:
>
> [14697.488452] CPU: 112 UID: 0 PID: 124791 Comm: hackbench Not tainted
> 7.1.0-rc2+
> [14697.492627] RIP: 0010:propagate_entity_load_avg+0x35f/0x3e0
> [14697.506799] <TASK>
> [14697.507411] __dequeue_task+0x2b4/0xc70
> [14697.508677] dequeue_task_fair+0x36/0x370
> [14697.509047] dequeue_task+0x101/0x2f0
> [14697.509426] __schedule+0x1b1/0x1a00
> [14697.510868] anon_pipe_read+0x3da/0x450
> [14697.511400] vfs_read+0x361/0x390
> [14697.512053] __x64_sys_read+0x19/0x30
>
> The divide-by-zero happens here:
>
> if (scale_load_down(gcfs_rq->load.weight)) {
> load_sum = div_u64(gcfs_rq->avg.load_sum,
> scale_load_down(gcfs_rq->load.weight));
> }
>
> gcfs_rq->load.weight is an insane large value and is truncated
> to the lower 32 bits by div_u64, which happen to be 0.
>
> Using AI for investigation, the cause is a u32 overflow in
> update_tg_cfs_runnable(), and flat pickup became a victim when using
> tg_tasks():
>
> u32 new_sum, divider;
> ...
> new_sum = se->avg.runnable_avg * divider; <-- boom
>
> The following sequence shows how this triggers the crash:
>
> propagate_entity_load_avg()
> update_tg_cfs_runnable() # u32 overflow corrupts runnable_sum
>
> __update_load_avg_cfs_rq()
> ___update_load_avg() # computes insane runnable_avg
> update_tg_load_avg() # propagates to tg->runnable_avg
>
> update_cfs_group()
> calc_concur_shares()
> tg_tasks() # long-to-int truncation, negative nr
> reweight_entity() # corrupted se->load.weight
> update_load_add() # corrupted cfs_rq->load.weight
>
> propagate_entity_load_avg()
> update_tg_cfs_load()
> div_u64() # divide-by-zero
>
> Fix by widening new_sum from u32 to u64(no need to force tg_tasks()
> to return unsigned long after this fix)
> Assisted-by: Claude:claude-opus-4.6
> Signed-off-by: Chen Yu <yu.c.chen@intel.com>
> ---
> kernel/sched/fair.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index d991ea85873a..99ea51448981 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5305,7 +5305,8 @@ static inline void
> update_tg_cfs_runnable(struct cfs_rq *cfs_rq, struct sched_entity *se, struct cfs_rq *gcfs_rq)
> {
> long delta_sum, delta_avg = gcfs_rq->avg.runnable_avg - se->avg.runnable_avg;
> - u32 new_sum, divider;
> + u64 new_sum;
> + u32 divider;
>
> /* Nothing to update */
> if (!delta_avg)
> @@ -5319,7 +5320,7 @@ update_tg_cfs_runnable(struct cfs_rq *cfs_rq, struct sched_entity *se, struct cf
>
> /* Set new sched_entity's runnable */
> se->avg.runnable_avg = gcfs_rq->avg.runnable_avg;
> - new_sum = se->avg.runnable_avg * divider;
> + new_sum = (u64)se->avg.runnable_avg * divider;
> delta_sum = (long)new_sum - (long)se->avg.runnable_sum;
> se->avg.runnable_sum = new_sum;
Hmm, nice one. This makes sense because sched_avg::runnable_sum is a u64
itself, so having the delta be one is only sensible.
I do wonder though, this doesn't actually look to be specific to flat,
it just managed to trip it somehow.
I'll stick this on as a separate fix.
next prev parent reply other threads:[~2026-06-26 11:40 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 12:40 [PATCH v3 0/7] sched: Flatten the pick Peter Zijlstra
2026-06-05 12:40 ` [PATCH v3 1/7] sched/fair: Add cgroup_mode switch Peter Zijlstra
2026-06-30 9:03 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2026-06-05 12:40 ` [PATCH v3 2/7] sched/fair: Add cgroup_mode: up Peter Zijlstra
2026-06-05 15:07 ` Peter Zijlstra
2026-06-30 9:03 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2026-06-05 12:40 ` [PATCH v3 3/7] sched/fair: Add cgroup_mode: max Peter Zijlstra
2026-06-10 15:09 ` Waiman Long
2026-06-10 15:42 ` Waiman Long
2026-06-11 13:49 ` Peter Zijlstra
2026-06-11 13:47 ` Peter Zijlstra
2026-06-11 20:57 ` Waiman Long
2026-06-30 9:03 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2026-06-05 12:40 ` [PATCH v3 4/7] sched/fair: Add cgroup_mode: concur Peter Zijlstra
2026-06-30 9:03 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2026-06-05 12:40 ` [PATCH v3 5/7] sched/fair: Add cgroup_mode: tasks Peter Zijlstra
2026-06-30 9:03 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2026-06-05 12:40 ` [PATCH v3 6/7] sched/fair: Change the default cgroup_mode to concur Peter Zijlstra
2026-06-30 9:03 ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
2026-06-05 12:40 ` [PATCH v3 7/7] sched/eevdf: Move to a single runqueue Peter Zijlstra
2026-06-20 3:54 ` Chen, Yu C
2026-06-26 11:40 ` Peter Zijlstra [this message]
2026-06-29 14:02 ` Vincent Guittot
2026-06-30 9:03 ` [tip: sched/core] sched/fair: Fix overflow in update_tg_cfs_runnable() tip-bot2 for Chen, Yu C
2026-06-30 9:03 ` [tip: sched/core] sched/eevdf: Move to a single runqueue tip-bot2 for Peter Zijlstra (Intel)
2026-06-09 5:37 ` [PATCH v3 0/7] sched: Flatten the pick K Prateek Nayak
2026-06-12 2:29 ` Shubhang Kaushik
2026-08-17 16:05 ` Szabina Korbai
2026-08-17 16:35 ` K Prateek Nayak
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=20260626114016.GZ42921@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bsegall@google.com \
--cc=cgroups@vger.kernel.org \
--cc=chenridong@huaweicloud.com \
--cc=dietmar.eggemann@arm.com \
--cc=hannes@cmpxchg.org \
--cc=jstultz@google.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=mkoutny@suse.com \
--cc=qyousef@layalina.io \
--cc=rostedt@goodmis.org \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=yu.c.chen@intel.com \
/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.