Re: [RFC PATCH] mm/damon/sysfs-schemes: hold damon_sysfs_lock in target_value_store()

[SJ Park]

On Tue, 20 Oct 2026 17:52:33 -0700 SJ Park <sj@xxxxxxxxxx> wrote:

> On Tue, 20 Oct 2026 07:47:25 -0700 SJ Park <sj@xxxxxxxxxx> wrote:
> 
> > Remove a race condition under certain use cases that can trigger
> > divide-by-zero.
> > 
> > damon_sysfs_add_quota_score() setup damos quota goal as user configured
> > and pass to the core layer.  Because it could have a race with
> > damos_sysfs_quota_goals_rm_dirs(), which destructs the files that carry
> > user configuration, both are called under damon_sysfs_lock protection.
> > 
> > The damos quota goal setup disallows zero target_value parameter because
> > it can be used as a denominator later in the core layer function,
> > damos_quota_score().  Otherwise, divide-by-zero can happen.
> 
> This is no more true due to another patch [1].  The patch added the zero
> target_value case in the core layer central validation pass.  But it forgot
> removing the redundant check in sysfs.
> 
> > 
> > For the zero value check and final assignment,
> > damon_sysfs_add_quota_score() reads damos_sysfs_quota_goal->target_value
> > twice.  And user can update damos_sysfs_quota_goal->target_value via
> > target_value_store(), which doesn't hold damon_sysfs_lock.  As a result,
> > a time-of-check-to time-of-use (toctou) race can happen.  If the user
> > sets the value to zero between the zero value check and final
> > target_value assignment, zero target_value is passed to the core layer
> > and results in divide-by-zero.
> 
> So toctou race exists, but it cannot result in divide-by-zero.

And the toctou doesn't matter because the final value based same check will be
made in the core layer.  But the toctou makes readers easy to be confused.  I
will post another patch removing the unnecessary zero value check.


Thanks,
SJ

[...]