Re: [PATCH 05/12] mm/damon/sysfs: remove probes number validation

[Kunwu Chan]

On Wed,  2 Sep 2026 07:37:06 -0700 SJ Park <sj@xxxxxxxxxx> wrote:

> On Wed,  2 Sep 2026 22:07:13 +0800 Kunwu Chan <kunwu.chan@xxxxxxxxx> wrote:
> 
> > On Tue,  1 Sep 2026 22:47:38 -0700 SJ Park <sj@xxxxxxxxxx> wrote:
> [...]
> > I was wondering whether DAMON_MAX_PROBES is purely a core invariant
> > or also an interface constraint.
> 
> Thank you for reviewing my patch and raising this question!
> 
> > 
> > With this change, sysfs allows nr_probes larger than
> > DAMON_MAX_PROBES and damon_sysfs_probes_add_dirs() will start creating
> > probe objects before the configuration is later rejected by
> > damon_valid_probe_params().
> > 
> > Since nr_probes directly controls the number of sysfs objects created,
> > do we still want to keep an early check here?
> > 
> > I agree that the core validation is required for non-sysfs callers,
> > but I am not sure whether this particular limit should be duplicated
> > at the sysfs layer.
> 
> I agree the user experience may be not that good.
> 
> In my humble opinion, however, keeping code simplicity is more important than
> the user experience here.  After all, DAMON_SYSFS is recommended to be used by
> another high level tools like DAMON user-space tool (damo) rather than human
> fingers.  The user-space tools like damo can do the early check.
> 
> Please feel free to let me know if you have any other opinions or questions.

Hi SJ,

Thanks for the explanation.

I agree that keeping the invariant validation in the core layer avoids
duplicating the limit in multiple places.  Your point about DAMON_SYSFS
being mainly consumed by higher-level tools like damo also makes sense.

My concern was mainly about the temporary creation of sysfs probe objects
before the configuration is rejected, rather than the user-facing error
message.  Given that the number of probes is bounded by the core
invariant anyway, I agree that keeping the validation centralized is a
reasonable trade-off.

Thanks for clarifying.

Reviewed-by: Kunwu Chan <kunwu.chan@xxxxxxxxx>

Thanks,
Kunwu

> 
> 
> Thanks,
> SJ
> 
> [...]
> 

Sent using hkml (https://github.com/sjp38/hackermail)