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

[Hao Jia]

On 2026/7/20 09:26, Hao Jia wrote:
> 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.

Hi Andrew, Yosry, and Nhat,
Any thoughts on this change?

Thanks,
Hao
> 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