Re: [PATCH v2 0/2] mm/zswap: Fixes and improves the zswap global shrinker

[Hao Jia]

On 2026/7/18 12:40, Andrew Morton wrote:
> On Fri, 17 Jul 2026 18:28:04 -0700 Yosry Ahmed <yosry@xxxxxxxxxx> wrote:
>
> > > The [1/2] changelog lacks a description of how the flaw impacts users.
> > > Please describe this fully and maintain that info within the
> > > changelogging.  This info helps -stable maintainers and others
> > > understand why we're proposing a backport and helps myself and others
> > > with timing decisions.
> >
> > The first line in the changelog should be sufficient imo: "Zswap
> > writeback on hitting the pool limit is broken when memory cgroup is
> > disabled"
>
> "broken"?  Perhaps this means "fails to occur".
>
> But what is the userspace-visible impact?  IOW, why are we proposing a
> backport?

Perhaps the first paragraph of the commit1 message could be modified as 
follows? I have added a description of the issues that occur without 
this patch.

Zswap writeback on hitting the pool limit fails to occur when memory 
cgroup is disabled, because mem_cgroup_iter() always returns NULL. 
Therefore, the global shrinker shrink_worker() always takes the !memcg 
branch. After MAX_RECLAIM_RETRIES empty walks, the worker simply gives 
up, so it fails to write back anything. As a result, once the pool 
reaches the zswap limit, every subsequent zswap shrink work run is a 
no-op. This leads to zswap store failures, forcing pages to bypass zswap 
and be written directly to the backing swap device, which can trigger 
issues such as LRU inversion.


Thanks,
Hao