[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20250604110442.8251-1-lirongqing@baidu.com>
Date: Wed, 4 Jun 2025 19:04:42 +0800
From: lirongqing <lirongqing@...du.com>
To: <mingo@...hat.com>, <peterz@...radead.org>, <juri.lelli@...hat.com>,
<vincent.guittot@...aro.org>, <dietmar.eggemann@....com>,
<rostedt@...dmis.org>, <bsegall@...gle.com>, <mgorman@...e.de>,
<vschneid@...hat.com>, <linux-kernel@...r.kernel.org>
CC: Li RongQing <lirongqing@...du.com>
Subject: [PATCH] sched/cputime: Fix a mostly theoretical divide by zero
From: Li RongQing <lirongqing@...du.com>
Sum of utime and stime can overflow to 0, when a process with
many threads run over total 2^64 ns
Signed-off-by: Li RongQing <lirongqing@...du.com>
---
kernel/sched/cputime.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 6dab4854..c35fc4c 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -579,7 +579,8 @@ void cputime_adjust(struct task_cputime *curr, struct prev_cputime *prev,
goto update;
}
- stime = mul_u64_u64_div_u64(stime, rtime, stime + utime);
+ if (likely(stime + utime))
+ stime = mul_u64_u64_div_u64(stime, rtime, stime + utime);
/*
* Because mul_u64_u64_div_u64() can approximate on some
* achitectures; enforce the constraint that: a*b/(b+c) <= a.
--
2.9.4
Powered by blists - more mailing lists