Re: (sashiko review) [RFC PATCH v5 01/10] mm/damon/core: introduce damon_ctx->paused

[SeongJae Park]

On Wed,  1 Apr 2026 18:10:42 -0700 SeongJae Park <sj@xxxxxxxxxx> wrote:

> On Mon, 23 Mar 2026 21:07:21 -0700 SeongJae Park <sj@xxxxxxxxxx> wrote:
> 
> > On Mon, 23 Mar 2026 18:28:00 -0700 SeongJae Park <sj@xxxxxxxxxx> wrote:
> > 
> > > Forwarding Sashiko review for doing discussions via mails.
> [...]
> > > Additionally, when the context is paused, kdamond_fn remains in this sleep
> > > loop and skips calling damos_adjust_quota(), which means quota->charged_from
> > > is frozen.
> > > 
> > > If the pause lasts for more than LONG_MAX jiffies (e.g., about 24.8 days on
> > > a 32-bit system with HZ=1000), will system jiffies wrap past the half-range
> > > limit of the unsigned long type relative to the frozen timestamp?
> > > 
> > > If this wraparound occurs, time_after_eq(jiffies, quota->charged_from +
> > > interval) would evaluate to false when unpaused. Would this cause the quota
> > > window to not reset for another 24.8 days, accumulating charged_sz and
> > > blocking the scheme from being applied?
> > 
> > That's a wild corner case, but I agree it is better to avoid the problematic
> > case.  I'm still thinking about the good way for that.  Anyway, I will address
> > this in the next spin.
> 
> The root cause of the issue was introduced before this patch, so I fixed it
> with another hotfix [1].  So next spin of this patch will have no change.

FWIW, I'm planning to post the next version of this series only after rebasing
to the latest mm-new, after the all MM pull requests for next -rc1 are merged.

> 
> [1] https://lore.kernel.org/20260329152306.45796-1-sj@xxxxxxxxxx


Thanks,
SJ

[...]