[<prev] [next>] [day] [month] [year] [list]
Message-ID: <d171fbe778f046b296618f21219078b0@baidu.com>
Date: Tue, 22 Jul 2025 02:09:04 +0000
From: "Li,Rongqing" <lirongqing@...du.com>
To: David Laight <david.laight.linux@...il.com>, Oleg Nesterov
<oleg@...hat.com>
CC: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>, "Dave
Hansen" <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>,
Steven Rostedt <rostedt@...dmis.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "x86@...nel.org" <x86@...nel.org>
Subject: 答复: [SPAM] [????] Re: [PATCH] x86/math64: handle #DE in mul_u64_u64_div_u64()
> Even for the scheduler that recently trapped here, the 64bit sum was about the
> wrap and the very small value returned then almost certainly wouldn't have
> been handled correctly.
> (So that code needs fixing anyway to avoid the overflow.)
There are currently two bugs. The one Oleg is fixing is a crash bug in the x86-64 mul_u64_u64_div_u64() function caused by potential overflow. The mul_u64_u64_div_u64() function is used not only in cputime.c ,but also widely used within drivers.
The other one is a thread group statistics time overflow bug. If the overflow of mul_u64_u64_div_u64() can be fixed, it at least doesn't crash the system anymore. However, regarding the accuracy of the timing statistics, this bug might be more harder to fix.
-Li
Powered by blists - more mailing lists