Re: [PATCH v9.1] mm/damon: add node_eligible_mem_bp goal metric

[SeongJae Park <sj@kernel.org>]

On Mon, 27 Apr 2026 01:24:29 +0000 sashiko-bot@kernel.org wrote:

> Sashiko AI review found 3 potential issue(s):
> - [High] Data truncation and arithmetic overflow in metric calculation on 32-bit systems.
> - [High] Missing `cond_resched()` inside the inner PFN-walking loop causes CPU soft lockups.

Not new Sashiko findings.  Above two issues are not real problems or better to
see if the issue can really happen.  I explained detailed reason on previous
Sashiko reviews.

> - [High] Address advancement logic is vulnerable to wrap-around infinite loops.

This is a new and good finding.  I asked a fix on my reply to the patch.

> --
> 
> commit 10100659661304515a414f3a15324e8278667f42
> Author: Ravi Jonnalagadda <ravis.opensrc@gmail.com>
> 
> mm/damon: add node_eligible_mem_bp goal metric
> 
> This commit introduces the DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP goal metric to
> track the ratio of scheme-eligible memory on a specific NUMA node, allowing
> the quota autotuner to adjust based on spatial memory distribution.
> 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index 3dbbbfdeff71..22d6eb3a974d 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> [ ... ]
> > +static phys_addr_t damos_calc_eligible_bytes(struct damon_ctx *c,
> > +		struct damos *s, int nid, phys_addr_t *total)
> > +{
> [ ... ]
> > +			/* Convert from core address units to physical bytes */
> > +			addr = (phys_addr_t)r->ar.start * c->addr_unit;
> > +			end_addr = (phys_addr_t)r->ar.end * c->addr_unit;
> > +			while (addr < end_addr) {
> > +				struct folio *folio;
> > +				phys_addr_t folio_start, folio_end;
> > +				phys_addr_t overlap_start, overlap_end;
> > +				phys_addr_t counted;
> > +
> > +				folio = damon_get_folio(PHYS_PFN(addr));
> > +				if (!folio) {
> > +					addr = PAGE_ALIGN_DOWN(addr + PAGE_SIZE);
> 
> If a DAMON region extends to the upper boundary of the physical address space,
> could addr + PAGE_SIZE overflow and wrap around to 0?
> 
> If addr wraps to 0, addr < end_addr would remain true, which might cause an
> unrecoverable infinite loop.

Good finding.  I asked another version for fix of this, on my reply to the
original patch.


Thanks,
SJ

[...]