Re: [RFC PATCH v3 1/9] mm/damon/paddr: remove page_fault access check primitive

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mm: incomplete removal of DAMON page_fault primitive breaks monitoring
--

commit f8b1b9b51e640cbb863657ba42563c571bdd1e32
Author: Ravi Jonnalagadda <ravis.opensrc@gmail.com>
Subject: mm/damon/paddr: remove page_fault access check primitive

This commit removes the page_fault access check primitive from DAMON, 
including the page fault reporting dispatch sites and support helpers, 
as part of a transition to perf-event probes.

[Severity: High]
Does this commit leave behind portions of the page_fault primitive that 
could silently break DAMON monitoring if configured by a user?

The underlying page_fault producer and dispatch hooks in mm/memory.c have 
been removed, but the frontend configuration and core dispatch logic appear 
to be left intact. 

Specifically, in mm/damon/sysfs-sample.c around line 593, 
damon_sysfs_set_sample_control() still parses and sets the removed 
page_fault configuration from the sysfs interface.

Furthermore, in mm/damon/core.c at line 2088, 
damon_primitives_enabled_invalid() still enforces that exactly one primitive 
must be enabled, allowing the page_fault path to be accepted as valid.

Finally, in the core kdamond loop within mm/damon/core.c at line 4393, 
kdamond_fn() still branches on the removed page_fault primitive. Because 
the backend producer is gone, this branch bypasses ops.check_accesses() 
and does no work, resulting in exactly zero accesses being recorded for 
all regions.

If a sysfs user configures DAMON with the page_fault primitive, could this 
cause catastrophic automated memory reclaim since all regions would falsely 
appear entirely cold?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261003-damon-perf-rfc-v3-send-2026-10-03-v3-0-0f00417b41bc@gmail.com?part=1