linux-kernel - Re: [PATCH] mm: vmscan: always allow writeback during memcg reclaim

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251215041200.GB905277@cmpxchg.org>
Date: Sun, 14 Dec 2025 23:12:00 -0500
From: Johannes Weiner <hannes@...xchg.org>
To: Deepanshu Kartikey <kartikey406@...il.com>
Cc: akpm@...ux-foundation.org, axelrasmussen@...gle.com, yuanchu@...gle.com,
	weixugc@...gle.com, david@...nel.org, mhocko@...nel.org,
	zhengqi.arch@...edance.com, shakeel.butt@...ux.dev,
	lorenzo.stoakes@...cle.com, yuzhao@...gle.com, heftig@...hlinux.org,
	oleksandr@...alenko.name, bgeffon@...gle.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	syzbot+90fcab4d88cffed6d0d8@...kaller.appspotmail.com
Subject: Re: [PATCH] mm: vmscan: always allow writeback during memcg reclaim

On Sat, Dec 13, 2025 at 02:06:39PM +0530, Deepanshu Kartikey wrote:
> When laptop_mode is enabled, may_writepage is set to 0 in
> try_to_free_mem_cgroup_pages(). This triggers a warning in MGLRU's
> lru_gen_shrink_lruvec():
> 
>     VM_WARN_ON_ONCE(!sc->may_writepage || !sc->may_unmap);
> 
> The warning occurs because MGLRU expects full reclaim capabilities to
> function correctly. The call path is:
> 
>     mem_cgroup_resize_max()
>       try_to_free_mem_cgroup_pages()
>         do_try_to_free_pages()
>           shrink_node()
>             shrink_lruvec()
>               lru_gen_shrink_lruvec()  <-- WARNING
> 
> Unlike kswapd or direct reclaim where laptop_mode's disk-saving behavior
> is a reasonable optimization, memcg limit enforcement is a hard
> requirement - memory MUST be freed when a cgroup exceeds its limit.

That reasoning doesn't make sense to me. Reclaim is always in response
to an allocation need. The laptop_mode idea applies to cgroup reclaim
as much as any other reclaim.

Now obviously all of this is pretty dated. Reclaim doesn't do
filesystem writes anymore, and I'm not sure there are a whole lot of
laptops with rotational drives left, either. Also I doubt anybody is
still using zone_reclaim_mode (which is where the may_unmap is from).

But let's not introduce more inconsistencies, please. The only thing
weird here is the MGLRU warning. What is it trying to assert? Clearly
whatever assumption was made here has never been true.

And what is the zone_reclaim_mode (may_unmap) assert doing in the
cgroup limit reclaim path?

It seems to me both the warning in cgroup reclaim, and the goto done
in root reclaim, are kind of unnecessary and gratuitously breaking
both laptop_mode and zone_reclaim_mode - obsolete as they may be. But
why even add this code?

Can somebody with MGLRU context please take a look whether we can
remove these?

> Set may_writepage unconditionally to 1 for memcg reclaim to ensure
> MGLRU works correctly and memory limits are properly enforced.
> 
> Fixes: bd74fdaea146 ("mm: multi-gen LRU: support page table walks")

That seems unrelated?