linux-kernel - Re: [PATCH v3 26/30 fix] mm: mglru: do not call update_lru

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aXBT0R42Xuzwr3Ns@hyeyoo>
Date: Wed, 21 Jan 2026 13:19:29 +0900
From: Harry Yoo <harry.yoo@...cle.com>
To: Qi Zheng <qi.zheng@...ux.dev>
Cc: hannes@...xchg.org, hughd@...gle.com, mhocko@...e.com,
        roman.gushchin@...ux.dev, shakeel.butt@...ux.dev,
        muchun.song@...ux.dev, david@...nel.org, lorenzo.stoakes@...cle.com,
        ziy@...dia.com, yosry.ahmed@...ux.dev, imran.f.khan@...cle.com,
        kamalesh.babulal@...cle.com, axelrasmussen@...gle.com,
        yuanchu@...gle.com, weixugc@...gle.com, chenridong@...weicloud.com,
        mkoutny@...e.com, akpm@...ux-foundation.org,
        hamzamahfooz@...ux.microsoft.com, apais@...ux.microsoft.com,
        lance.yang@...ux.dev, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        cgroups@...r.kernel.org, Qi Zheng <zhengqi.arch@...edance.com>
Subject: Re: [PATCH v3 26/30 fix] mm: mglru: do not call update_lru_size()
 during reparenting

On Wed, Jan 21, 2026 at 12:53:28PM +0900, Harry Yoo wrote:
> On Thu, Jan 15, 2026 at 06:44:44PM +0800, Qi Zheng wrote:
> > From: Qi Zheng <zhengqi.arch@...edance.com>
> > 
> > Only non-hierarchical lruvec_stats->state_local needs to be reparented,
> > so handle it in reparent_state_local(), and remove the unreasonable
> > update_lru_size() call in __lru_gen_reparent_memcg().
> 
> Hmm well, how are the hierarchical statistics consistent when pages are
> reparented from an "active" gen to an "inactive" gen, or the other way around?
> 
> They'll become inconsistent when those pages are reclaimed or
> moved between generations?

FYI we've observed this while testing downstream implementation
as it led to MemAvailable being unreasonably high due to inconsistent
statistics.

The solution was, if lru_gen_is_active(child, gen) and
lru_gen_is_active(parent, gen) do not match, # of pages being
reparented must be subtracted from the child's statistics
(and up to the root, as it's hierarchical), and added to the parent's
statistics for the generation.

-- 
Cheers,
Harry / Hyeonggon