Some DAMON sysfs directory setup functions generates its sub and sub-sub
directories.  For example, 'monitoring_attrs/' directory setup creates
'intervals/' and 'intervals/intervals_goal/' directories under
'monitoring_attrs/' directory.  When such sub-sub directories are
successfully made but followup setup is failed, the setup function
should recursively clean up the subdirectories.

However, such setup functions are only dereferencing sub directory
reference counters.  As a result, under certain setup failures, the
sub-sub directories keep having non-zero reference counters.   It means
the directories cannot be removed like zombies, and the memory for the
directories cannot be freed.

The user impact of this issue is limited due to the following reasons.

When the issue happens, the zombie directories are still taking the
path.  Hence attempts to generate the directories again will fail,
without additional memory leak.  This means the upper bound memory leak
is limited.  Nonetheless this also implies controlling DAMON with a
feature that requires the setup-failed sysfs files will be impossible
until the system reboots.

Also, the setup operations are quite simple.  The certain failures would
hence only rarely happen, and are difficult to artificially trigger.

SeongJae Park (4):
  mm/damon/sysfs: cleanup intervals subdirs on attrs dir setup failure
  mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure
  mm/damon/sysfs-scheme: cleanup quotas subdirs on scheme dir setup
    failure
  mm/damon/sysfs-scheme: cleanup access_pattern subdirs on scheme dir
    setup failure

 mm/damon/sysfs-schemes.c | 10 ++++++----
 mm/damon/sysfs.c         |  9 ++++++---
 2 files changed, 12 insertions(+), 7 deletions(-)


base-commit: 6d039da6a260dd7919bebc70ebb65d250bb9c24e
-- 
2.47.3

Hello Andrew, happy new year!

On Wed, 24 Dec 2025 18:30:33 -0800 SeongJae Park <sj@kernel.org> wrote:

> Some DAMON sysfs directory setup functions generates its sub and sub-sub
> directories.  For example, 'monitoring_attrs/' directory setup creates
> 'intervals/' and 'intervals/intervals_goal/' directories under
> 'monitoring_attrs/' directory.  When such sub-sub directories are
> successfully made but followup setup is failed, the setup function
> should recursively clean up the subdirectories.
> 
> However, such setup functions are only dereferencing sub directory
> reference counters.  As a result, under certain setup failures, the
> sub-sub directories keep having non-zero reference counters.   It means
> the directories cannot be removed like zombies, and the memory for the
> directories cannot be freed.
> 
> The user impact of this issue is limited due to the following reasons.
> 
> When the issue happens, the zombie directories are still taking the
> path.  Hence attempts to generate the directories again will fail,
> without additional memory leak.  This means the upper bound memory leak
> is limited.  Nonetheless this also implies controlling DAMON with a
> feature that requires the setup-failed sysfs files will be impossible
> until the system reboots.
> 
> Also, the setup operations are quite simple.  The certain failures would
> hence only rarely happen, and are difficult to artificially trigger.

The user impact of the bugs is limited as explained above, but the bugs exist
in the code for real world usages.  I therefore expected this series would be
added to mm-hotfixes-unstable.

Do you have any concern at treating this series as hotfixes?  If not, could you
please move this series into mm-hotfixes-unstable?


Thanks,
SJ

[...]

On Fri,  2 Jan 2026 16:21:37 -0800 SeongJae Park <sj@kernel.org> wrote:

> > Also, the setup operations are quite simple.  The certain failures would
> > hence only rarely happen, and are difficult to artificially trigger.
> 
> The user impact of the bugs is limited as explained above, but the bugs exist
> in the code for real world usages.  I therefore expected this series would be
> added to mm-hotfixes-unstable.
> 
> Do you have any concern at treating this series as hotfixes?  If not, could you
> please move this series into mm-hotfixes-unstable?

Sure, I have made that change.