Re: [PATCH v5 1/6] mm/memcontrol: move the lru_zone_size sanity check to the reader side

[Shakeel Butt]

On Wed, Sep 02, 2026 at 05:50:54PM +0800, Kairui Song via B4 Relay wrote:
> From: Kairui Song <kasong@xxxxxxxxxxx>
> 
> Instead of using an unsigned long and checking the counter value at
> the updater side, turn the counter into a signed long and check at the
> reader side. This reduces overhead and simplifies the code.
> 
> commit ca707239e8a7 ("mm: update_lru_size warn and reset bad lru_size")
> added a sanity check for memcg counter underflow: lru_zone_size is
> unsigned, so an underflow wraps it around and returns an enormously
> large number, then the memcg shrinker loops almost forever as the
> calculated number of folios to shrink is huge. It also checked if a
> zero value matches the empty LRU list, so the positive and negative
> deltas had to be handled separately. However that emptiness check was
> already removed by commit b4536f0c829c ("mm, memcg: fix the active list
> aging for lowmem requests when memcg is enabled"), so handling the
> deltas separately is no longer needed.
> 
> The remaining update-side check is costly and cannot really catch the
> leak it is after anyway. It runs on every LRU folio, and if a folio was
> removed without updating the counter while other folios remain on the
> LRU, the WARN only triggers much later, from a likely innocent
> callsite. While readers are much rarer than writers, only the reclaim
> and reparenting paths read it, once per batch.
> 
> Checking at the reader side instead leaves the update path a plain
> addition, and puts the warning where the value is actually consumed.
> 
> Note this changes the behavior on underflow: the correction is removed
> and a negative value is kept. A massive leak of the LRU size counter
> would indicate that something else has gone very wrong, and one should
> fix that leaking site instead. Besides, the original behavior might
> cause false positives, or make things worse if the accounting happens
> after the actual insertion: the value is not leaked, just delayed, so
> force-fixing it would cause a bigger problem. The warning now only kicks
> in when a consumer actually uses it, in which case the reader gets zero.
> 
> Reviewed-by: Ridong Chen <ridong.chen@xxxxxxxxx>
> Reviewed-by: Barry Song <baohua@xxxxxxxxxx>
> Signed-off-by: Kairui Song <kasong@xxxxxxxxxxx>

Acked-by: Shakeel Butt <shakeel.butt@xxxxxxxxx>