Re: [PATCH 6.1.y 1/2] mm/damon/core: implement damon_kdamond_pid()

[SeongJae Park <sj@kernel.org>]

On Thu, 14 May 2026 01:39:23 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The commit message references a non-existent function `damon_is_running()` and makes inaccurate claims about the current state of API callers.
> --
> 
> commit 79a54a37fc83e2191edada566d0eb1ab79303fd8
> Author: SeongJae Park <sj@kernel.org>
> 
> mm/damon/core: implement damon_kdamond_pid()
> 
> This commit hides the kdamond and kdamond_lock fields from DAMON API callers
> by implementing a new damon_kdamond_pid() function to retrieve the worker
> thread's PID.
> 
> Link: https://lkml.kernel.org/r/20260115152047.68415-1-sj@kernel.org
> Link: https://lkml.kernel.org/r/20260115152047.68415-2-sj@kernel.org
> 
> > For the first use case, a dedicated API function, namely
> > 'damon_is_running()' is provided, and all DAMON API callers are using the
> > function for the use case.
> 
> Is damon_is_running() actually present in the codebase at this point?
> 
> The commit message states that damon_is_running() is provided and all API
> callers are using it, but it appears this function does not exist in the
> codebase at the time of this commit. It seems to only be introduced in the
> subsequent patch "mm/damon/lru_sort: detect and use fresh enabled and
> kdamond_pid values" as a backported dependency.
> 
> Furthermore, API callers like mm/damon/sysfs.c (via
> damon_sysfs_ctx_running()) still directly check ctx->kdamond != NULL under
> kdamond_lock.
> 
> Could this description be inaccurate, perhaps due to patches being applied
> out of order during a backport?

Sashiko is correct, this description is inaccurate.  But that's intentional for
stable kernel backports.

> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/2026051243-crevice-spool-75d8@gregkh?part=1


Thanks,
SJ