Re: [BUG] DAMON_STAT: 32-bit overflow reports wrong estimated bandwidth

[SJ Park <sj@kernel.org>]

Hi Aveline,

On Thu, 15 Oct 2026 04:24:19 -0700 Aveline Noir <jm5905938@gmail.com> wrote:

> Hi,
> 
> On an unmodified i386 QEMU kernel at mm-new commit ad9f2d463666,
> DAMON_STAT reported an incorrect estimated_memory_bandwidth value.
> CONFIG_DAMON_STAT=y and CONFIG_DAMON_STAT_ENABLED_DEFAULT=y were set.
> The guest continuously wrote one byte per page across a 32 MiB mapping.
> I used QEMU's GDB stub and the matching vmlinux to stop just after
> damon_stat_set_estimated_memory_bandwidth() stored its result.  At each
> stop, I traversed the same target's regions separately and recomputed
> access_bytes with full-width integers.
> 
> Three nonzero callbacks, all with aggr_interval=100000 us, showed:
> 
>   access_bytes   independent sum   stored B/s   full-width B/s
>       33357824          33357824        31079        333578240
>       65200128          65200128        25244        652001280
>       41152512          41152512        24303        411525120
> 
> The final sysfs read was estimated_memory_bandwidth=24303, matching the
> last stored value.  The independent region sum matched the kernel's
> access_bytes in every callback, so the sum had not overflowed.  Each
> full-width result fits a 32-bit unsigned long.
> 
> In mm/damon/stat.c, the expression multiplies the unsigned long
> access_bytes by 1000000 before dividing by the aggregation interval.
> On i386 the product wraps.  In the first row it becomes 3107979264;
> dividing by 100000 gives the stored value, 31079.  Full-width arithmetic
> gives 333578240 B/s from the same inputs.  The other two rows show the
> same problem at the callback site.
> 
> The workload is synthetic; the test checks DAMON_STAT's arithmetic, not
> the accuracy of its traffic estimate.  The i386 config, guest init,
> disassembly, GDB probe, logs, and build/run steps are here:

Could you share more details about your use case that require this setup, and
how this becomes a problem?


Thanks,
SJ

[...]