mm/damon/core: handle zero intervals in damon_max_nr_accesses()
Subsystems (3)
SeongJae Park
maintainerRFC PATCH 1/1 mm/damon/core: handle zero intervals in damon_max_nr_accesses()
damon_max_nr_accesses() causes a divide-by-zero if the sampling interval is set to zero by the user. If the aggregation interval is set to zero, the function returns zero. It is wrong, since the real maximum nr_acceses in the setup should be one. Worse yet, it can causes another divide-by-zero from its caller, damon_hot_score(), since it uses damon_max_nr_accesses() return value as a denominator.
Fix the problem by setting the denominator in the function as 1 when the sampling interval is zero. Also ensure the return value is always 1 or greater.
The issue was dicovered [1] by Sashiko.
[1] https://lore.kernel.org/[email protected]
---
Changes from RFC v1
- rfc v1: https://lore.kernel.org/[email protected]
- Handle zero aggr_interval case.
include/linux/damon.h | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
include/linux/damon.h +6 -2
@@ -1066,9 +1066,13 @@ static inline bool damon_target_has_pid(const struct damon_ctx *ctx)static inline unsigned int damon_max_nr_accesses (const struct damon_attrs *attrs) { -/* {aggr,sample}_interval are unsigned long, hence could overflow */ -return min (attrs->aggr_interval / attrs->sample_interval, +unsigned long sample_interval; +unsigned long max_nr_accesses; + + sample_interval = attrs->sample_interval ? :1 ; + max_nr_accesses =min (attrs->aggr_interval / sample_interval, (unsigned long )UINT_MAX ); +return max_nr_accesses ? :1 ; }
base-commit: 7a58ae62cdf3c006a53b805bbb12079ab2621a07
Signature · 1 line
2.47.3
[email protected]
AI reviewThank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Pre-existing integer overflows when scaling nr_accesses based on user-defined intervals. --
commit 2fc9b9ee26cec1a6b183b74636dd1922579cd4da
Author: SeongJae Park <[email protected]>
mm/damon/core: handle zero intervals in damon_max_nr_accesses()
damon_max_nr_accesses() causes a divide-by-zero if the sampling interval is set to zero by the user. If the aggregation interval is set to zero, the function returns zero. It is wrong, since the real maximum nr_acceses in the setup should be one.
Quoted 8 lines
include/linux/damon.h +0
-0@@ -1065,9 +1065,13 @@ static inline bool damon_target_has_pid(const struct damon_ctx *ctx)static inline unsigned int damon_max_nr_accesses (const struct damon_attrs *attrs) {
include/linux/damon.h static inline bool damon_target_has_pid(const struct damon_ctx *ctx) · line 1075
Quoted 10 lines
include/linux/damon.h +6
-2-/* {aggr,sample}_interval are unsigned long, hence could overflow */ -return min (attrs->aggr_interval / attrs->sample_interval, +unsigned long sample_interval; +unsigned long max_nr_accesses; + + sample_interval = attrs->sample_interval ? :1 ; + max_nr_accesses =min (attrs->aggr_interval / sample_interval, (unsigned long )UINT_MAX ); +return max_nr_accesses ? :1 ; }
[Severity: High]
This is a pre-existing issue, but are there integer overflows when scaling nr_accesses based on these user-defined intervals?
Since DAMON allows configuring sample_interval and aggr_interval via sysfs without restricting their ratio, a region's nr_accesses (an unsigned int) can grow up to aggr_interval / sample_interval.
If this ratio exceeds UINT_MAX, nr_accesses wraps around. More practically, the codebase multiplies nr_accesses by 32-bit integer constants:
In mm/damon/core.c:damon_merge_two_regions():
l->nr_accesses_bp = l->nr_accesses * 10000;
Can this overflow 32-bit unsigned math if the access count is greater than 429,496?
Similarly, in mm/damon/ops-common.c:damon_hot_score():
freq_subscore = r->nr_accesses * DAMON_MAX_SUBSCORE / damon_max_nr_accesses(&c->attrs);
Does natively multiplying r->nr_accesses by 100 before dividing by the max accesses cause a 32-bit integer overflow if the accesses exceed 42,949,672?
Additionally, on 32-bit platforms, can this calculation overflow unsigned long?
In mm/damon/lru_sort.c:damon_lru_sort_apply_parameters():
hot_thres = damon_max_nr_accesses(&attrs) * hot_thres_access_freq / 1000;
Multiplying damon_max_nr_accesses (up to UINT_MAX) by hot_thres_access_freq natively overflows unsigned long on 32-bit architectures.
Could these overflows corrupt DAMON's core metrics, potentially causing incorrect memory operations like aggressively swapping out hot pages under the false impression that they are cold?
Signature · 1 line
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1
SeongJae Park
maintainerQuoted 64 lines · On Sat, 20 Jun 2026 17:25:02 +0000 [email protected] wrote:
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Pre-existing integer overflows when scalingnr_accessesbased on user-defined intervals. --commit
2fc9b9ee26cec1a6b183b74636dd1922579cd4da
Author: SeongJae Park <[email protected]>
mm/damon/core: handle zero intervals indamon_max_nr_accesses()
damon_max_nr_accesses()causes a divide-by-zero if the sampling interval is set to zero by the user. If the aggregation interval is set to zero, the function returns zero. It is wrong, since the real maximumnr_accesesin the setup should be one.Quoted 8 lines
include/linux/damon.h +0
-0@@ -1065,9 +1065,13 @@ static inline bool damon_target_has_pid(const struct damon_ctx *ctx)static inline unsigned int damon_max_nr_accesses (const struct damon_attrs *attrs) {include/linux/damon.h static inline bool damon_target_has_pid(const struct damon_ctx *ctx) · line 1075
Quoted 10 lines
include/linux/damon.h +6
-2-/* {aggr,sample}_interval are unsigned long, hence could overflow */ -return min (attrs->aggr_interval / attrs->sample_interval, +unsigned long sample_interval; +unsigned long max_nr_accesses; + + sample_interval = attrs->sample_interval ? :1 ; + max_nr_accesses =min (attrs->aggr_interval / sample_interval, (unsigned long )UINT_MAX ); +return max_nr_accesses ? :1 ; }[Severity: High]
This is a pre-existing issue, but are there integer overflows when scalingnr_accessesbased on these user-defined intervals?Since DAMON allows configuring
sample_intervalandaggr_intervalvia sysfs without restricting their ratio, a region'snr_accesses(an unsigned int) can grow up toaggr_interval/sample_interval.If this ratio exceeds
UINT_MAX,nr_accesseswraps around. More practically, the codebase multipliesnr_accessesby 32-bit integer constants:In mm/damon/core.c:damon_merge_two_regions():
l->nr_accesses_bp = l->nr_accesses * 10000;Can this overflow 32-bit unsigned math if the access count is greater than 429,496?
Similarly, in mm/damon/ops-common.c:damon_hot_score():
freq_subscore = r->nr_accesses * DAMON_MAX_SUBSCORE / damon_max_nr_accesses(&c->attrs);Does natively multiplying
r->nr_accessesby 100 before dividing by the max accesses cause a 32-bit integer overflow if the accesses exceed 42,949,672?Additionally, on 32-bit platforms, can this calculation overflow unsigned long?
In mm/damon/lru_sort.c:damon_lru_sort_apply_parameters():
Quoted 8 lines
hot_thres = damon_max_nr_accesses(&attrs) * hot_thres_access_freq / 1000;Multiplying
damon_max_nr_accesses(up toUINT_MAX) byhot_thres_access_freqnatively overflows unsigned long on 32-bit architectures.Could these overflows corrupt DAMON's core metrics, potentially causing incorrect memory operations like aggressively swapping out hot pages under the false impression that they are cold?
We believe this happens only under very weird setup that is not realistic, and hence ignoring this kind of issues for now. We could revisit if a user claims this as an issue.
Thanks,
SJ
[...]