linux-kernel - Re: [PATCH -next 1/5] mm/mglru: use mem_cgroup

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: <c4fjngkwbjlfnbjl5merldg5k2fiu43p46osagmy3ibr62cgxh@oesgt5l35kns>
Date: Mon, 22 Dec 2025 13:18:11 -0800
From: Shakeel Butt <shakeel.butt@...ux.dev>
To: Chen Ridong <chenridong@...weicloud.com>
Cc: akpm@...ux-foundation.org, axelrasmussen@...gle.com, 
	yuanchu@...gle.com, weixugc@...gle.com, david@...nel.org, lorenzo.stoakes@...cle.com, 
	Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org, surenb@...gle.com, 
	mhocko@...e.com, corbet@....net, hannes@...xchg.org, roman.gushchin@...ux.dev, 
	muchun.song@...ux.dev, zhengqi.arch@...edance.com, linux-mm@...ck.org, 
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, cgroups@...r.kernel.org, 
	lujialin4@...wei.com, zhongjinji@...or.com
Subject: Re: [PATCH -next 1/5] mm/mglru: use mem_cgroup_iter for global
 reclaim

On Mon, Dec 22, 2025 at 03:27:26PM +0800, Chen Ridong wrote:
> 
[...]
> 
> >> -		if (should_abort_scan(lruvec, sc))
> >> +		if (should_abort_scan(lruvec, sc)) {
> >> +			if (cookie)
> >> +				mem_cgroup_iter_break(target, memcg);
> >>  			break;
> > 
> > This seems buggy as we may break the loop without calling
> > mem_cgroup_iter_break(). I think for kswapd the cookie will be NULL and
> > if should_abort_scan() returns true, we will break the loop without
> > calling mem_cgroup_iter_break() and will leak a reference to memcg.
> > 
> 
> Thank you for catching that—my mistake.
> 
> This also brings up another point: In kswapd, the traditional LRU iterates through all memcgs, but
> stops for the generational LRU (GENLRU) when should_abort_scan is met (i.e., enough pages are
> reclaimed or the watermark is satisfied). Shouldn't both behave consistently?
> 
> Perhaps we should add should_abort_scan(lruvec, sc) in shrink_node_memcgs for the traditional LRU as
> well?

We definitely should discuss about should_abort_scan() for traditional
reclaim but to keep things simple, let's do that after this series. For
now, follow Johannes' suggestion of lru_gen_should_abort_scan().