mm/damon: fix DAMOS bugs in core, paddr and vaddr

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Medium] The patch incompletely fixes the uninitialized last_psi_total variable usage. While it initializes last_psi_total when the kdamond thread starts, it fails to initialize it for schemes or quota goals added dynamically at runtime via sysfs. --

--- Patch [2]: [RFC PATCH v1.1 2/9] mm/damon/core: initialize damos_quota_goal->last_psi_total --- commit ca3c4694fe111f676d0de56148cf986c02532428
Author: SJ Park <[email protected]>

mm/damon/core: initialize damos_quota_goal->last_psi_total

When DAMOS_QUOTA_SOME_MEM_PSI_US metric damos quota goal is set, the PSI delta for the feedback loop is calculated using damos_quota_goal->last_psi_total. It is not initialized at the beginning. This commit initializes the value at the beginning of kdamond.

Link https://lore.kernel.org/[email protected] open here

Quoted 4 lines

mm/damon/core.c +0 -0

index e2900d0c984c9..3bdbf4fbf7147 100644

[ ... ]

mm/damon/core.c static void kdamond_init_ctx(struct damon_ctx *ctx) · line 3758

Quoted 5 lines

mm/damon/core.c +1 -0

@@ -3744,6 +3755,7 @@ static void kdamond_init_ctx(struct damon_ctx *ctx)
 	damon_for_each_scheme(scheme, ctx) {
 		damos_set_next_apply_sis(scheme, ctx);
 		damos_set_filters_default_reject(scheme);
+		damos_init_quota_goal_last_psi(scheme);

[Severity: Medium]
This is a pre-existing issue, but does this completely fix the uninitialized variable usage?

While this initializes last_psi_total when the kdamond thread starts, it appears goals added dynamically at runtime via sysfs will still be uninitialized.

When a goal is parsed from sysfs, memory is allocated without zeroing the structure, leaving last_psi_total filled with slab garbage:

mm/damon/sysfs-schemes.c:damos_sysfs_add_quota_score() {
    ...
    goal = damos_new_quota_goal(sysfs_goal->metric,
            sysfs_goal->target_value);
    ...
}

During the context commit phase, the goal is dynamically allocated but last_psi_total is intentionally bypassed:

mm/damon/core.c:damos_commit_quota_goals() {
    ...
    new_goal = damos_new_quota_goal(
            src_goal->metric, src_goal->target_value);
    ...
}

When the feedback loop executes, this uninitialized memory is consumed:

mm/damon/core.c:damos_set_quota_goal_current_value() {
    ...
    goal->current_value = now_psi_total - goal->last_psi_total;
    ...
}

Will this cause a random, extremely large or small initial quota adjustment when a user adds a new DAMON scheme or quota goal with the DAMOS_QUOTA_SOME_MEM_PSI_US metric to a running context via sysfs?

Quoted 3 lines

mm/damon/core.c +0 -0

 	}
 }

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the patch provides an incomplete fix for an address advancement logic bug. While it corrects the addr += folio_size(folio) issue in damon_pa_stat() to correctly align the next address to the end of the large folio, it fails to apply the exact same fix to damon_pa_pageout(), damon_pa_de_activate(), and damon_pa_migrate(). --

--- Patch [3]: [RFC PATCH v1.1 3/9] mm/damon/paddr: respect folio end for DAMOS_STAT --- commit 99e0c032eda9c903df8d327aa77b989129d9b193
Author: SJ Park <[email protected]>

mm/damon/paddr: respect folio end for DAMOS_STAT

This commit fixes the address advancement in damon_pa_stat(). When a region starts in the middle of a large folio, it now properly aligns to the start of the next folio instead of simply adding the folio size and overshooting.

mm/damon/paddr.c static unsigned long damon_pa_stat(struct damon_region *r, · line 382

Quoted 9 lines

mm/damon/paddr.c +1 -1

@@ -379,7 +379,7 @@ static unsigned long damon_pa_stat(struct damon_region *r,
 
 		if (!damos_pa_filter_out(s, folio))
 			*sz_filter_passed += folio_size(folio) / addr_unit;
-		addr += folio_size(folio);
+		addr = PFN_PHYS(folio_pfn(folio)) + folio_size(folio);

[Severity: High]
This isn't a bug introduced by this patch, but does the same address advancement logic regression still exist in other DAMON actions?

While you fixed the overshoot behavior here in damon_pa_stat(), it looks like damon_pa_pageout(), damon_pa_de_activate(), and damon_pa_migrate() in mm/damon/paddr.c might still be using the flawed logic.

For example, in damon_pa_pageout():

    put_folio:
		addr += folio_size(folio);
		folio_put(folio);

Could this cause DAMON actions to silently skip sections of valid memory if a region starts in the middle of a large folio?

Quoted 4 lines

mm/damon/paddr.c +0 -0

 		folio_put(folio);
 	}
 	s->last_applied = folio;

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unsafe blind PTE batching skips intermediate mappings and misses per-PTE Accessed/Young bits for large folios. --

--- Patch [5]: [RFC PATCH v1.1 5/9] mm/damon/vaddr: respect folio end for DAMOS_STAT --- commit d6ffeea9e85e0fc3aa2c2575b8113904f9da4123
Author: SJ Park <[email protected]>

mm/damon/vaddr: respect folio end for DAMOS_STAT

This commit fixes an issue in DAMOS_STAT page-level monitoring where the address advancement could incorrectly skip folios if a region starts in the middle of a large folio. It ensures the address is advanced exactly to the start of the next folio by calculating the correct page index.

[1] https://lore.kernel.org/[email protected]

Quoted 4 lines

mm/damon/vaddr.c +0 -0

index 0648400b2d65b..4b0b5edf67952 100644

[ ... ]

mm/damon/vaddr.c static int damos_va_stat_pmd_entry(pmd_t *pmd, unsigned long addr, · line 850

Quoted 7 lines

mm/damon/vaddr.c +2 -1

@@ -844,7 +846,8 @@ static int damos_va_stat_pmd_entry(pmd_t *pmd, unsigned long addr,
 
 		if (!damos_va_filter_out(s, folio, vma, addr, pte, NULL))
 			*sz_filter_passed += folio_size(folio);
-		nr = folio_nr_pages(folio);
+		page_idx = folio_page_idx(folio, pte_page(ptent));
+		nr = folio_nr_pages(folio) - page_idx;

[Severity: High]
This is a pre-existing issue, but does this blind PTE batching skip intermediate mappings and miss per-PTE Accessed/Young bits for large folios?

When damos_va_filter_out() tests the young filter, it only checks the accessed bit of the first pte. By unconditionally advancing pte += nr without aggregating the accessed bits of the remaining subpages, could this miss hardware accesses on PTE-mapped large folios (like mTHP) and cause DAMON to falsely classify actively used memory as cold?

Additionally, if userspace partially unmaps or remaps portions of this large folio (for example, via MADV_DONTNEED or mmap), the page table might contain different folios or empty entries in the skipped range. By blindly advancing the PTE walker based purely on the first folio's size, does this ignore those mixed mappings and fail to monitor the substituted folios?

Quoted 4 lines

mm/damon/vaddr.c +0 -0

 		s->last_applied = folio;
 	}
 	pte_unmap_unlock(start_pte, ptl);

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=5

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [High] Returning 0 for DAMOS_QUOTA_NODE_MEM_FREE_BP when freeram > totalram incorrectly forces maximum scheme aggressiveness instead of reporting 100% free memory.
- [Medium] The commit message contradicts the implementation, and the unconditional return of 10000 for zero totalram breaks metric semantics.

Pre-existing issues:
- [High] Unhandled integer underflow in MEM_USED_BP and MEMCG_FREE_BP calculations when counters drift.
- [High] The patch fixes a potential divide-by-zero in damos_get_node_mem_bp() but misses identical unvalidated divisions in related functions. --

--- Patch [7]: [RFC PATCH v1.1 7/9] mm/damon/core: handle extreme memory state in damon_get_node_mem_bp() --- commit 05d27d4d51952669ff23ec9285ccb83a273556ad
Author: SJ Park <[email protected]>

mm/damon/core: handle extreme memory state in damon_get_node_mem_bp()

In an extreme and unlikely situation, si_meminfo_node() might let the caller show zero total ram. That could cause a divide by zero in damon_get_node_mem_bp(). Fix it by setting the totalram one byte in the case.

Link https://lore.kernel.org/[email protected] open here

Quoted 4 lines

In an extreme and unlikely situation, si_meminfo_node() might let the caller show zero total ram. That could cause a divide by zero in damon_get_node_mem_bp(). Fix it by setting the totalram one byte in the case.

[Severity: Medium]
The commit message states "Fix it by setting the totalram one byte in the case."

However, the implementation actually bypasses the metric type check and returns 10000.

Does this unconditional return contradict the intent documented in the commit message?

mm/damon/core.c static __kernel_ulong_t damos_get_node_mem_bp( · line 2820

Quoted 12 lines

mm/damon/core.c +2 -1

index 3bdbf4fbf7147..e3f3ee75a3d33 100644
@@ -2816,10 +2816,16 @@ static __kernel_ulong_t damos_get_node_mem_bp(
 	}
 
 	si_meminfo_node(&i, goal->nid);
-	if (goal->metric = DAMOS_QUOTA_NODE_MEM_USED_BP)
+	if (!i.totalram)
+		return 10000;

[Severity: Medium]
If the metric is DAMOS_QUOTA_NODE_MEM_FREE_BP, shouldn't it report 0% free rather than 100% free if the memory is absent (which is what totalram=1, freeram=0 would yield)?

Does returning 10000 here break the semantic constraint that used + free = 100%?

mm/damon/core.c static __kernel_ulong_t damos_get_node_mem_bp( · line 2822

Quoted 3 lines

mm/damon/core.c +1 -0

+	if (goal->metric = DAMOS_QUOTA_NODE_MEM_USED_BP) {
 		numerator = i.totalram - i.freeram;

[Severity: High]
This is a pre-existing issue, but if counter drift results in freeram > totalram, does this subtraction silently underflow, producing a massive unsigned value?

If this is passed to mult_frac(), could it generate a huge metric value, leading the auto-tuner to mistakenly act as if the memory is massively overused?

An identical unhandled underflow also appears to exist in damos_get_node_memcg_used_bp() when evaluating DAMOS_QUOTA_NODE_MEMCG_FREE_BP if used_pages exceeds totalram:

mm/damon/core.c:damos_get_node_memcg_used_bp() {
    ...
    numerator = i.totalram - used_pages;
    ...
}

mm/damon/core.c static __kernel_ulong_t damos_get_node_mem_bp( · line 2826

Quoted 6 lines

mm/damon/core.c +4 -1

-	else	/* DAMOS_QUOTA_NODE_MEM_FREE_BP */
+	} else {
+		/* DAMOS_QUOTA_NODE_MEM_FREE_BP */
+		if (i.totalram < i.freeram)
+			return 0;

[Severity: High]
When counter drift causes freeram > totalram, the node effectively has ~100% free memory.

By returning 0 (0% free memory) in this scenario, doesn't the DAMON quota auto-tuning feedback loop interpret this as severely under-achieving the free memory goal, causing it to wastefully and drastically increase the reclamation budget (e.g., pageout/demotion) on a node that is already completely free?

Should this return 10000 (100% free) instead?

mm/damon/core.c static __kernel_ulong_t damos_get_node_mem_bp( · line 2830

Quoted 5 lines

mm/damon/core.c +1 -0

 		numerator = i.freeram;
+	}
 	return mult_frac(numerator, 10000, i.totalram);
 }

[Severity: High]
This is a pre-existing issue, but while this patch addresses a potential divide-by-zero when si_meminfo_node() reports totalram = 0, does the same unvalidated division exist in related functions?

For example, damos_get_node_memcg_used_bp() divides by i.totalram without a zero-check:

mm/damon/core.c:damos_get_node_memcg_used_bp() {
    ...
    si_meminfo_node(&i, goal->nid);
    ...
    return mult_frac(numerator, 10000, i.totalram);
}

Similarly, damos_get_in_active_mem_bp() divides by total (active + inactive) via mult_frac() without checking if total is zero:

mm/damon/core.c:damos_get_in_active_mem_bp() {
    ...
    if (goal->metric = DAMOS_QUOTA_SOME_MEM_USED_BP)
        return mult_frac(active, 10000, total);
    return mult_frac(inactive, 10000, total);
}

Signature · 2 lines

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=7

Quoted 33 lines · On Sun, 02 Aug 2026 16:35:44 +0000 [email protected] wrote:

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [High] Returning 0 for DAMOS_QUOTA_NODE_MEM_FREE_BP when freeram > totalram incorrectly forces maximum scheme aggressiveness instead of reporting 100% free memory.
- [Medium] The commit message contradicts the implementation, and the unconditional return of 10000 for zero totalram breaks metric semantics.

Pre-existing issues:
- [High] Unhandled integer underflow in MEM_USED_BP and MEMCG_FREE_BP calculations when counters drift.
- [High] The patch fixes a potential divide-by-zero in damos_get_node_mem_bp() but misses identical unvalidated divisions in related functions. --

--- Patch [7]: [RFC PATCH v1.1 7/9] mm/damon/core: handle extreme memory state in damon_get_node_mem_bp() --- commit 05d27d4d51952669ff23ec9285ccb83a273556ad
Author: SJ Park <[email protected]>

mm/damon/core: handle extreme memory state in damon_get_node_mem_bp()

In an extreme and unlikely situation, si_meminfo_node() might let the caller show zero total ram. That could cause a divide by zero in damon_get_node_mem_bp(). Fix it by setting the totalram one byte in the case.

Link https://lore.kernel.org/[email protected] open here

Quoted 4 lines

In an extreme and unlikely situation, si_meminfo_node() might let the caller show zero total ram. That could cause a divide by zero in damon_get_node_mem_bp(). Fix it by setting the totalram one byte in the case.

[Severity: Medium]
The commit message states "Fix it by setting the totalram one byte in the case."

Quoted 5 lines

However, the implementation actually bypasses the metric type check and returns 10000.

Does this unconditional return contradict the intent documented in the commit message?

Good catch, I will update the commit message.

Quoted 18 lines

mm/damon/core.c static __kernel_ulong_t damos_get_node_mem_bp( · line 2820

Quoted 12 lines

mm/damon/core.c +2 -1

index 3bdbf4fbf7147..e3f3ee75a3d33 100644
@@ -2816,10 +2816,16 @@ static __kernel_ulong_t damos_get_node_mem_bp(
 	}
 
 	si_meminfo_node(&i, goal->nid);
-	if (goal->metric = DAMOS_QUOTA_NODE_MEM_USED_BP)
+	if (!i.totalram)
+		return 10000;

[Severity: Medium]
If the metric is DAMOS_QUOTA_NODE_MEM_FREE_BP, shouldn't it report 0% free rather than 100% free if the memory is absent (which is what totalram=1, freeram=0 would yield)?

Quoted 1 line

Does returning 10000 here break the semantic constraint that used + free = 100%?

I made mistakes at revisioning. I will fix this.

Quoted 18 lines

mm/damon/core.c static __kernel_ulong_t damos_get_node_mem_bp( · line 2822

Quoted 4 lines

mm/damon/core.c +1 -0

+	if (goal->metric = DAMOS_QUOTA_NODE_MEM_USED_BP) {
 		numerator = i.totalram - i.freeram;

[Severity: High]
This is a pre-existing issue, but if counter drift results in freeram > totalram, does this subtraction silently underflow, producing a massive unsigned value?

If this is passed to mult_frac(), could it generate a huge metric value, leading the auto-tuner to mistakenly act as if the memory is massively overused?

An identical unhandled underflow also appears to exist in damos_get_node_memcg_used_bp() when evaluating DAMOS_QUOTA_NODE_MEMCG_FREE_BP if used_pages exceeds totalram:

Quoted 5 lines

mm/damon/core.c:damos_get_node_memcg_used_bp() {
    ...
    numerator = i.totalram - used_pages;
    ...
}

The intention of this revision was handling this, but I made a complete mistake. I will fix.

Quoted 11 lines

mm/damon/core.c static __kernel_ulong_t damos_get_node_mem_bp( · line 2826

Quoted 6 lines

mm/damon/core.c +4 -1

-	else	/* DAMOS_QUOTA_NODE_MEM_FREE_BP */
+	} else {
+		/* DAMOS_QUOTA_NODE_MEM_FREE_BP */
+		if (i.totalram < i.freeram)
+			return 0;

[Severity: High]
When counter drift causes freeram > totalram, the node effectively has ~100% free memory.

Quoted 6 lines

By returning 0 (0% free memory) in this scenario, doesn't the DAMON quota auto-tuning feedback loop interpret this as severely under-achieving the free memory goal, causing it to wastefully and drastically increase the reclamation budget (e.g., pageout/demotion) on a node that is already completely free?

Should this return 10000 (100% free) instead?

That depends on the perspective. I think 0% makes sense.

Quoted 24 lines

mm/damon/core.c static __kernel_ulong_t damos_get_node_mem_bp( · line 2830

Quoted 5 lines

mm/damon/core.c +1 -0

 		numerator = i.freeram;
+	}
 	return mult_frac(numerator, 10000, i.totalram);
 }

[Severity: High]
This is a pre-existing issue, but while this patch addresses a potential divide-by-zero when si_meminfo_node() reports totalram = 0, does the same unvalidated division exist in related functions?

For example, damos_get_node_memcg_used_bp() divides by i.totalram without a zero-check:

mm/damon/core.c:damos_get_node_memcg_used_bp() {
    ...
    si_meminfo_node(&i, goal->nid);
    ...
    return mult_frac(numerator, 10000, i.totalram);
}

Similarly, damos_get_in_active_mem_bp() divides by total (active + inactive) via mult_frac() without checking if total is zero:

Quoted 6 lines

mm/damon/core.c:damos_get_in_active_mem_bp() {
    ...
    if (goal->metric = DAMOS_QUOTA_SOME_MEM_USED_BP)
        return mult_frac(active, 10000, total);
    return mult_frac(inactive, 10000, total);
}

Later patches in this series fix those.

Quoted 1 line

Quoted 3 lines

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=7

Thanks,
SJ

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but damos_get_node_mem_bp() contains a severe logic bug and underflow when free memory exceeds total memory (i.totalram < i.freeram). --

--- Patch [8]: [RFC PATCH v1.1 8/9] mm/damon/core: handle extreme memory state in get_node_memcg_used_bp() --- commit 0fb31bc202c766c30f5d776d57b867135fba4aa6
Author: SJ Park <[email protected]>
mm/damon/core: handle extreme memory state in get_node_memcg_used_bp()

This commit addresses division by zero and underflow issues in damos_get_node_memcg_used_bp() by handling cases where total memory is zero or used memory exceeds total memory. It returns 100% and 0% for these respective edge cases to prevent anomalous behavior.

Link https://lore.kernel.org/[email protected] open here

Quoted 8 lines

mm/damon/core.c +0 -0

index e3f3ee75a3d33..67ad1f07c29a4 100644
@@ -2862,10 +2862,16 @@ static unsigned long damos_get_node_memcg_used_bp(
 	mem_cgroup_put(memcg);
 
 	si_meminfo_node(&i, goal->nid);

mm/damon/core.c static unsigned long damos_get_node_memcg_used_bp( · line 2872

Quoted 10 lines

mm/damon/core.c +7 -2

-	if (goal->metric = DAMOS_QUOTA_NODE_MEMCG_USED_BP)
+	if (!i.totalram)
+		return 10000;
+	if (goal->metric = DAMOS_QUOTA_NODE_MEMCG_USED_BP) {
 		numerator = used_pages;
-	else	/* DAMOS_QUOTA_NODE_MEMCG_FREE_BP */
+	} else {
+		/* DAMOS_QUOTA_NODE_MEMCG_FREE_BP */
+		if (i.totalram < used_pages)
+			return 0;

[Severity: High]
This isn't a bug introduced by this patch, but does the adjacent damos_get_node_mem_bp() function contain a logic bug when free memory exceeds total memory?

If i.totalram < i.freeram, it appears that for DAMOS_QUOTA_NODE_MEM_USED_BP, i.totalram - i.freeram will unconditionally underflow, falsely throttling or activating schemes. For DAMOS_QUOTA_NODE_MEM_FREE_BP, returning 0 means it reports 0% free memory when the node is actually >100% free, which could cause schemes waiting for low free memory to trigger aggressively.

mm/damon/core.c:damos_get_node_mem_bp() {
	...
	if (goal->metric = DAMOS_QUOTA_NODE_MEM_USED_BP) {
		numerator = i.totalram - i.freeram;
	} else {
		/* DAMOS_QUOTA_NODE_MEM_FREE_BP */
		if (i.totalram < i.freeram)
			return 0;
		numerator = i.freeram;
	}
	...
}

Should this pre-existing issue in damos_get_node_mem_bp() be addressed as well, perhaps by returning 0 for USED_BP and 10000 for FREE_BP when i.totalram < i.freeram?

Quoted 5 lines

mm/damon/core.c +1 -0

 		numerator = i.totalram - used_pages;
+	}
 	return mult_frac(numerator, 10000, i.totalram);
 }

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=8

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] 32-bit integer overflows and truncations in DAMON memory metric calculations cause wildly incorrect quota logic on 32-bit architectures. --

--- Patch [9]: [RFC PATCH v1.1 9/9] mm/damon/core: handle extreme memory state in get_in_active_mem_bp() --- commit e72445b8d3c8d0866c458b7707c7433d7912c2e6
Author: SJ Park <[email protected]>

mm/damon/core: handle extreme memory state in get_in_active_mem_bp()

This commit addresses a divide-by-zero issue in damos_get_in_active_mem_bp(). It ensures the denominator is at least 1 when calculating the ratio of active or inactive memory, preventing a crash if both are zero.

Link https://lore.kernel.org/[email protected] open here

mm/damon/core.c static unsigned int damos_get_in_active_mem_bp(bool active_ratio) · line 3018

Quoted 11 lines

mm/damon/core.c +1 -1

index 67ad1f07c29a4..c79b854e1a971 100644
@@ -3014,7 +3014,7 @@ static unsigned int damos_get_in_active_mem_bp(bool active_ratio)
 		global_node_page_state(NR_LRU_BASE + LRU_ACTIVE_FILE);
 	inactive = global_node_page_state(NR_LRU_BASE + LRU_INACTIVE_ANON) +
 		global_node_page_state(NR_LRU_BASE + LRU_INACTIVE_FILE);
-	total = active + inactive;
+	total = max(active + inactive, 1);
 	if (active_ratio)

[Severity: High]
This is a pre-existing issue, but does this code overflow 32-bit unsigned math on 32-bit architectures?

The mult_frac(x, n, d) macro computes (x / d) * n + (x % d) * n / d. Since n is 10000, the multiplication x * 10000 is performed using 32-bit unsigned arithmetic on 32-bit systems (where unsigned long is 32 bits). If active memory exceeds 429,496 pages (~1.76 GB), the multiplication overflows ULONG_MAX, resulting in an incorrect ratio.

Does this same overflow also affect other DAMON memory metric calculations? For example, in damos_get_node_eligible_mem_bp():

return mult_frac((unsigned long)node_eligible, 10000,
(unsigned long)total_eligible);

This explicitly casts a 64-bit phys_addr_t to unsigned long, truncating capacities over 4GB on 32-bit systems. It also overflows mult_frac() if the eligible memory exceeds just ~419 KB.

Similarly, in damon_get_intervals_score():

    max_access_events += sz_region * c->attrs.aggr_samples;
    access_events += sz_region * r->nr_accesses;

Because sz_region is in bytes, accumulating these into an unsigned long seems to overflow for regions larger than a few tens of megabytes.

Quoted 4 lines

mm/damon/core.c +0 -0

 		return mult_frac(active, 10000, total);
 	return mult_frac(inactive, 10000, total);

}

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=9