Re: [PATCH v2] mm/shmem, swap: fix race of truncate and swap entry split

[Andrew Morton <akpm@linux-foundation.org>]

On Mon, 19 Jan 2026 10:17:50 +0800 Kairui Song <ryncsn@gmail.com> wrote:

> >
> > What tree was this prepared against?
> >
> > Both Linus mainline and mm.git have
> >
> > : static long shmem_free_swap(struct address_space *mapping,
> > :                           pgoff_t index, void *radswap)
> > : {
> > :       int order = xa_get_order(&mapping->i_pages, index);
> > :       void *old;
> > :
> > :       old = xa_cmpxchg_irq(&mapping->i_pages, index, radswap, NULL, 0);
> > :       if (old != radswap)
> > :               return 0;
> > :       free_swap_and_cache_nr(radix_to_swp_entry(radswap), 1 << order);
> > :
> > :       return 1 << order;
> > : }
> >
> > but that free_swap_and_cache_nr() call is absent from your tree.
> 
> Oh, I tested and sent this patch based on mm-unstable, because the bug
> was found while I was testing swap table series. This is a 2 year old
> existing bug though. Swapoff during high system pressure is not a very
> common thing, and maybe mTHP for shmem is currently not very commonly
> used either? So maybe that's why no one found this issue.
> 
> free_swap_and_cache_nr is renamed to swap_put_entries_direct in
> mm-unstable, it's irrelevant to this fix or bug. The rename change was
> made here:
> https://lore.kernel.org/linux-mm/20251220-swap-table-p2-v5-14-8862a265a033@tencent.com/
> 
> Should I resend this patch base on the mainline and rebase that
> series? Or should we merge this in mm-unstable first then I can
> send seperate fixes for stable?

I think a clean fix against Linus mainline, please.  Then let's take a
look at what's needed to repair any later problems.