Re: [PATCH] mm/zswap: fix double decrement of the LRU node count on writeback

[Nhat Pham]

On Wed, Oct 28, 2026 at 9:15 PM Kaitao Cheng <kaitao.cheng@xxxxxxxxx> wrote:
>
>
>
> 在 2026/10/29 02:47, Nhat Pham 写道:
> > On Wed, Oct 28, 2026 at 4:36 AM Kaitao Cheng <kaitao.cheng@xxxxxxxxx> wrote:
> >>
> >> From: Kaitao Cheng <chengkaitao@xxxxxxxxxx>
> >>
> >> Successful writeback calls zswap_entry_free(), which removes the entry
> >> from the LRU and decrements both the sublist and node item counts.
> >> shrink_memcg_cb() then returns LRU_REMOVED_RETRY, causing the LRU walker
> >> to decrement the node count again.
> >>
> >> The affected call path before this change is:
> >>
> >>   __list_lru_walk_one()
> >>     shrink_memcg_cb()
> >>       zswap_writeback_entry()
> >>         zswap_entry_free()
> >>           zswap_lru_del()
> >>             list_lru_del()
> >>               __list_lru_del()
> >>                 atomic_long_dec()  /* first node count decrement */
> >>       return LRU_REMOVED_RETRY
> >>     atomic_long_dec()              /* second node count decrement */
> >>
> >> Add zswap_lru_del_nocnt() to remove the entry and update only the sublist
> >> count, leaving node accounting to the walker. Split data cleanup into
> >> __zswap_entry_free() so writeback can free the entry without performing
> >> another LRU deletion. Other free paths retain their existing accounting.
> >
> > What is the visible effect? Is there any effect, be it in reclaim
> > dynamics or userspace counters? Can you add it to the changelog?
> >
> > I'm not against fixing it, but need to gauge the effect for
> > prioritization, whether to cc stable etc. etc.
> >
>
> This is only an accounting issue; I could not find any code in zswap that
> reads lru->node[nid].nr_items.

Yeah I double checked - this is the node counter
(list_lru_node->nr_items). zswap uses the per-node-per-memcg counter
(list_lru_one->nr_items).

I think Johannes' approach SGTM.