Re: [PATCH 6.12.y] mm/damon/paddr: drop last same folio access check reuse optimization

[sashiko-bot@kernel.org]

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 it is a pre-existing TOCTOU race in `damon_folio_young` where an anonymous folio can be converted to a KSM folio after lockless checks, leading to `rmap_walk_ksm` being called without the folio lock.
--

commit fca283b4eb28ba2daec6fc0d0f8aed873b1ec9ca
Author: SJ Park <sj@kernel.org>

mm/damon/paddr: drop last same folio access check reuse optimization

This commit removes a race-prone optimization in damon's physical address
monitoring that attempted to reuse access check results for the same folio.
The optimization provided doubtful benefits while introducing potential races
when multiple kdamonds run.

Link: https://lore.kernel.org/20260715031002.108504-5-sj@kernel.org
Link: https://lore.kernel.org/20260621204050.10993-1-sj@kernel.org [1]

> diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c
> index d4a4d51750f5f..a6b1de97b1e8a 100644
> --- a/mm/damon/paddr.c
> +++ b/mm/damon/paddr.c

[ ... ]

> @@ -157,7 +157,6 @@ static bool damon_pa_young(unsigned long paddr, unsigned long *folio_sz)
>  		return false;
>  
>  	accessed = damon_folio_young(folio);

[Severity: High]
This is a pre-existing issue, but is there a time-of-check to time-of-use
race in damon_folio_young() when handling anonymous folios?

When damon_pa_check_access() calls damon_pa_young(), it takes a speculative
reference to the folio and calls damon_folio_young(). Inside
damon_folio_young(), the need for a lock is determined locklessly:

damon_folio_young() {
        need_lock = !folio_test_anon(folio) || folio_test_ksm(folio);
        if (need_lock && !folio_trylock(folio))
                return false;
        
        rmap_walk(folio, &rwc);
}

If the ksm daemon is concurrently processing an anonymous folio, could the
lockless check evaluate to false just before the ksm daemon updates
the folio with the ksm flag?

If that sequence occurs, damon_folio_young() would skip acquiring the
folio lock and call rmap_walk(). The rmap_walk() function would then
re-evaluate the ksm flag, see it is set, and call rmap_walk_ksm() without
holding the required folio lock.

Could this lead to a panic or data corruption when walking the ksm stable
tree locklessly?

> -	*folio_sz = folio_size(folio);
>  	folio_put(folio);
>  	return accessed;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909053646.245843-1-sj@kernel.org?part=1