Re: [RFC PATCH v2 07/10] selftests/damon/_damon_sysfs: support pause file staging

SeongJae Park
2026-03-20T15:22:15Z

On Wed, 18 Mar 2026 22:21:50 -0700 SeongJae Park <sj@kernel.org> wrote:

> DAMON test-purpose sysfs interface control Python module, _damon_sysfs,
> is not supporting the newly added pause file. Add the support of the
> file, for future test and use of the feature.
>
> Signed-off-by: SeongJae Park <sj@kernel.org>
> ---
> tools/testing/selftests/damon/_damon_sysfs.py | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/damon/_damon_sysfs.py b/tools/testing/selftests/damon/_damon_sysfs.py
> index 2b4df655d9fd0..120b96ecbd741 100644
> --- a/tools/testing/selftests/damon/_damon_sysfs.py
> +++ b/tools/testing/selftests/damon/_damon_sysfs.py
> @@ -604,10 +604,11 @@ class DamonCtx:
> targets = None
> schemes = None
> kdamond = None
> + pause = None
> idx = None
>
> def __init__(self, ops='paddr', monitoring_attrs=DamonAttrs(), targets=[],
> - schemes=[]):
> + schemes=[], pause=False):

Sashiko comment
(https://sashiko.dev/#/patchset/20260319052157.99433-8-sj@kernel.org) and my
reply.

: Since this line is being modified, could the use of mutable default
: arguments for monitoring_attrs, targets, and schemes cause unintended
: state sharing between instances?
:
: In Python, default arguments are evaluated exactly once at function
: definition time. If multiple DamonCtx objects are instantiated without
: explicitly providing these parameters, they will share the exact same
: object instances in memory.
:
: When the constructor later executes self.monitoring_attrs.context = self,
: it overwrites the context reference of the shared object to point to the
: newest DamonCtx instance. If multiple contexts are staged concurrently
: relying on the default arguments, earlier contexts might inadvertently
: write their sysfs files into the directory of the last created context.
:
: Would it be better to use None for the defaults and instantiate new objects
: inside the constructor?

Good points. Orthogonal to this patch, though. Also, there is no such use
case of this class to my best knowledge. I will consider such change later,
though.

Thanks,
SJ …