[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260103002139.66559-1-sj@kernel.org>
Date: Fri, 2 Jan 2026 16:21:37 -0800
From: SeongJae Park <sj@...nel.org>
To: SeongJae Park <sj@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
"# 5 . 18 . x" <stable@...r.kernel.org>,
Jiapeng Chong <jiapeng.chong@...ux.alibaba.com>,
damon@...ts.linux.dev,
linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH 0/4] mm/damon/sysfs: free setup failures generated zombie sub-sub dirs
Hello Andrew, happy new year!
On Wed, 24 Dec 2025 18:30:33 -0800 SeongJae Park <sj@...nel.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
[...]
Powered by blists - more mailing lists