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

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

[Aveline Noir]

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:

  https://github.com/jm5905938/kernel-mail/tree/195d7017352a3d0f4a0475b98f3b03650f5c14ea/cases/2026/damon/2026-10-15-bug-reports/04-stat-bandwidth-32bit-overflow

Thanks,
Aveline Noir

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

[SJ Park]

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

[...]

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

[Aveline Noir]

Hi SJ,

I haven't seen this affect a real workload. I found it while testing
DAMON_STAT on 32-bit.

I used a 32 MiB page-touching workload to get nonzero samples and GDB
to check the calculation. For one sample, the kernel reported 31079 B/s,
while full-width arithmetic gives 333578240 B/s from the same inputs.

A tool using this estimate to compare memory access intensity could
get the wrong picture.

Thanks,
Aveline Noir


On Thu, 15 Oct 2026 07:14:41 -0700, SJ Park <sj@kernel.org> wrote:
> 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
>
> [...]