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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aUBKRDkIqlisJzF-@tiehlicka>
Date: Mon, 15 Dec 2025 18:49:56 +0100
From: Michal Hocko <mhocko@...e.com>
To: Johannes Weiner <hannes@...xchg.org>
Cc: Deepanshu Kartikey <kartikey406@...il.com>, akpm@...ux-foundation.org,
	axelrasmussen@...gle.com, yuanchu@...gle.com, weixugc@...gle.com,
	david@...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 Sun 14-12-25 23:12:00, Johannes Weiner wrote:
> 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.

Completely agreed. This patch seems to just paper over a warning that
seems dubious while doing something that doesn't make much sense in
itself. Dropping laptop_mode from the memory reclaim seems like the
right direction anyway. I seriously doubt that it makes any practical or
measurable difference even on slow rotating storage laptops these days.

-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ