Re: [RESEND RFC PATCH v2 5/5] mm/damon/vaddr: implement DAMOS_SPLIT handler

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incorrect address range expansion and iteration logic in `damos_va_split()` causes out-of-bounds folio processing and skips memory.
- [High] `damos_va_split()` calls `split_folio_to_order()` on mapped compound pages without verifying they are valid LRU folios, leading to kernel crashes.
--

commit 1aa5abadd8058bacb6959d3c7864cfd3e927e6df
Author: Lian Wang <lianux.mm@gmail.com>

mm/damon/vaddr: implement DAMOS_SPLIT handler

This commit implements the vaddr operations layer handler for DAMOS_SPLIT.
It iterates over the target region and attempts to split any large folios
that exceed the scheme's target order.

> diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
> index 8bfc6dcc635d5..73cb61c655fc7 100644
> --- a/mm/damon/vaddr.c
> +++ b/mm/damon/vaddr.c
> @@ -940,6 +940,83 @@ static unsigned long damos_va_collapse(struct damon_target *target,
>  	return applied;
>  }
>  
> +static unsigned long damos_va_split(struct damon_target *target,
> +		struct damon_region *r, struct damos *s,
> +		unsigned long *sz_filter_passed)
> +{
> +	unsigned long addr, end, chunk_sz;
> +	unsigned int target_order = s->target_order;
> +	unsigned long applied = 0;
> +	struct mm_struct *mm;
> +	struct vm_area_struct *vma;
> +	struct folio *folio;
> +	struct folio_walk fw;
> +
> +	mm = damon_get_mm(target);
> +	if (!mm)
> +		return 0;
> +
> +	chunk_sz = PAGE_SIZE << HPAGE_PMD_ORDER;
> +	addr = ALIGN_DOWN(r->ar.start, chunk_sz);
> +	end = ALIGN(r->ar.end, chunk_sz);

[Severity: High]
Does aligning the start and end to 2MB boundaries risk processing memory outside
the requested target region? It seems this could expand the iteration beyond
the boundaries defined by r->ar.start and r->ar.end.

> +	if (end < addr)
> +		goto out_mmput;
> +
> +	while (addr < end) {
> +		unsigned long folio_sz;
> +
> +		if (addr + chunk_sz < addr)
> +			break;
> +
> +		mmap_read_lock(mm);
> +		vma = find_vma(mm, addr);
> +
> +		if (!vma || addr < vma->vm_start ||
> +		    vma->vm_flags & (VM_HUGETLB | VM_MIXEDMAP))
> +			goto unlock;
> +
> +		folio = folio_walk_start(&fw, vma, addr, 0);
> +		if (!folio)
> +			goto unlock;
> +
> +		folio_sz = PAGE_SIZE << folio_order(folio);
> +
> +		if (folio_order(folio) > target_order) {
> +			if (!folio_trylock(folio)) {
> +				folio_walk_end(&fw, vma);
> +				goto unlock;
> +			}
> +			folio_get(folio);
> +			folio_walk_end(&fw, vma);
> +
> +			if (!split_folio_to_order(folio, target_order))

[Severity: High]
Could this call to split_folio_to_order() encounter driver-allocated compound
pages? 

While VM_MIXEDMAP and VM_HUGETLB are filtered out, other normal VMAs
might still be backed by compound pages that are not fully initialized LRU
folios. Without checking if the folio is actually a valid LRU folio (e.g., via
folio_test_lru()), this might dereference uninitialized fields during the split
and cause kernel crashes.

> +				applied += folio_sz;
> +
> +			folio_unlock(folio);
> +			folio_put(folio);
> +			*sz_filter_passed += folio_sz;
> +			addr += folio_sz;
> +		} else {
> +			folio_walk_end(&fw, vma);
> +			*sz_filter_passed += chunk_sz;
> +			addr += chunk_sz;

[Severity: High]
When the folio order is smaller than or equal to the target order, does advancing
addr by a full 2MB chunk miss the remaining folios within that chunk? 

If addr was advanced by folio_sz in a previous loop iteration, adding chunk_sz
here might overshoot and skip memory.

> +		}
> +		mmap_read_unlock(mm);
> +		cond_resched();
> +		continue;
> +
> +unlock:
> +		*sz_filter_passed += chunk_sz;
> +		addr += chunk_sz;

[Severity: High]
Similarly, does advancing by chunk_sz on error paths (like missing VMAs, holes,
or lock failures) skip intermediate memory and artificially inflate the
sz_filter_passed statistic?

> +		mmap_read_unlock(mm);
> +		cond_resched();
> +	}
> +
> +out_mmput:
> +	mmput(mm);
> +	return applied;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702095227.75866-1-lianux.mm@gmail.com?part=5